Multilib/multiarch debuginfo

[Jussi Lehtola]

Hi,


is there any way to get i386 debuginfo packages on x86_64 for e.g.
libraries that are available also in 32-bit mode?
-- 
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org

[Roland McGrath]

>  is there any way to get i386 debuginfo packages on x86_64 for e.g.
>  libraries that are available also in 32-bit mode? 
They are only in the i386 debuginfo repositories, not copied in x86_64/debug.
I looked for a --arch= option to yum or suchlike, but I couldn't find a
way to do it.

[Jesse Keating]

On Thu, 2009-04-16 at 13:36 -0700, Roland McGrath wrote:
>  > is there any way to get i386 debuginfo packages on x86_64 for
> e.g.
>  > libraries that are available also in 32-bit mode?
>  
>  They are only in the i386 debuginfo repositories, not copied in x86_64/debug.
>  I looked for a --arch= option to yum or suchlike, but I couldn't find a
>  way to do it. 
Debuginfo is not made multilib.  That pathway leads to insanity.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Roland McGrath]

>  Debuginfo is not made multilib.  That pathway leads to insanity.
Sure.  What I was looking for was a way to tell yum to use a different
$basearch in repo lookup for one command.  That way may also lead to
insanity, I'm no authority on such things.  Another adequate option would
be some specialized yum-utils tool that can be told to go look at an
other-arch repo.  e.g. debuginfo-install --arch=i386 or something.

For some packages (kernel, bootloaders) even installing a debuginfo rpm
from a wholly other arch (--ignorearch) is actually useful and sensical.

Even just a "show me the rpm urls" and not trying to do any actual yumish
install operation would probably be useful to developers.  Maybe just a
repoquery option for other-arch repo lookups.


Thanks,
Roland

[James Antill]

On Thu, 2009-04-16 at 15:00 -0700, Roland McGrath wrote:
>  > Debuginfo is not made multilib.  That pathway leads to
> insanity.
>  
>  Sure.  What I was looking for was a way to tell yum to use a different
>  $basearch in repo lookup for one command.  That way may also lead to
>  insanity, I'm no authority on such things.  Another adequate option would
>  be some specialized yum-utils tool that can be told to go look at an
>  other-arch repo.  e.g. debuginfo-install --arch=i386 or something. 
 A few of the yum-utils commands take a --archlist, repoquery and
yumdownloader both do for instance. This is more for looking at data on
ppc from an i386 box, as i386 is already in the archlist for x86_64.
 And that doesn't change what $basearch will be in the config. files
because doing that is a really bad idea due to the fact that you'll have
changed what /var/cache/yum/blah/ points to without the next run of yum
knowing (it's a bad idea to have the same repoid point to more than one
place).

 So what you probably want is to create a blah-i386 to go with your
normal blah repo. ... which hardcodes i386 as the arch. Leave it
disabled, and then whever you want to use it do:

 yumdownloader --repoid=blah-i386 whatever...

 yum --disablerepo='*' --enablerepo=blah-i386 whatever...

...you can use yum-plugin-aliases to simply the later, if you want.

-- 
James Antill - james(a)fedoraproject.org
"I'd just like to see a realistic approach to updates via
 packages." -- Les Mikesell

[Roland McGrath]

>   A few of the yum-utils commands take a --archlist, repoquery and
>  yumdownloader both do for instance. This is more for looking at data on
>  ppc from an i386 box, as i386 is already in the archlist for x86_64. 
  ^^^

You meant x86_64 here, I think.  I noticed that switch and noticed that it
didn't help for this case.

>   And that doesn't change what $basearch will be in the config.
> files
>  because doing that is a really bad idea due to the fact that you'll have
>  changed what /var/cache/yum/blah/ points to without the next run of yum
>  knowing (it's a bad idea to have the same repoid point to more than one
>  place). 
Right, I figured that would be the gotcha with what I had in mind.
Maybe it would make sense for yum to name its cache subdirs repo.basearch?

>   So what you probably want is to create a blah-i386 to go with your
>  normal blah repo. ... which hardcodes i386 as the arch. Leave it
>  disabled, and then whever you want to use it do: 
It seems like a simple enough change to use basearch in the cache dir
names.  Then everyone could do this for all the repos without fiddling with
repo configs.  Does that seem like something yum could do in the future?
(I'm not asking for any of this to be done next week or anything.)

Maybe also --repoid et al could grok "reponame.arch" syntax (akin to the
package "name.arch" syntax you can use).  Another way to state it is that
the full "repoid" would be "reponame.arch", and "reponame"
alone turns into
"reponame.$basearch" implicitly.


Thanks,
Roland

[Josh Boyer]

On Fri, Apr 17, 2009 at 2:19 PM, Roland McGrath <roland(a)redhat.com&gt; wrote:
> >  A few of the yum-utils commands take a --archlist, repoquery
> and
> > yumdownloader both do for instance. This is more for looking at data on
> > ppc from an i386 box, as i386 is already in the archlist for x86_64.
>   ^^^
>
>  You meant x86_64 here, I think.  I noticed that switch and noticed that it
>  didn't help for this case.
>
> >  And that doesn't change what $basearch will be in the config. files
> > because doing that is a really bad idea due to the fact that you'll have
> > changed what /var/cache/yum/blah/ points to without the next run of yum
> > knowing (it's a bad idea to have the same repoid point to more than one
> > place).
>
>  Right, I figured that would be the gotcha with what I had in mind.
>  Maybe it would make sense for yum to name its cache subdirs repo.basearch?
>
> >  So what you probably want is to create a blah-i386 to go with your
> > normal blah repo. ... which hardcodes i386 as the arch. Leave it
> > disabled, and then whever you want to use it do:
>
>  It seems like a simple enough change to use basearch in the cache dir
>  names.  Then everyone could do this for all the repos without fiddling with
>  repo configs.  Does that seem like something yum could do in the future?
>  (I'm not asking for any of this to be done next week or anything.)
>
>  Maybe also --repoid et al could grok "reponame.arch" syntax (akin to the
>  package "name.arch" syntax you can use).  Another way to state it is that
>  the full "repoid" would be "reponame.arch", and "reponame"
> alone turns into
>  "reponame.$basearch" implicitly. 
Not that it helps today, but there is an F12 feature called
DebuginfoFS that is supposed to make stuff like this easier.  It might
be worthwhile to get the mutltilib things sorted out there too.

josh

[Will Woods]

On Fri, 2009-04-17 at 14:32 -0400, Josh Boyer wrote:

>  Not that it helps today, but there is an F12 feature called
>  DebuginfoFS that is supposed to make stuff like this easier.  It might
>  be worthwhile to get the mutltilib things sorted out there too. 
Not necessary; all debuginfo files have unique filenames, so we don't
need to know what arch the binaries are.

-w

[James Antill]

On Fri, 2009-04-17 at 11:19 -0700, Roland McGrath wrote:
>  >  A few of the yum-utils commands take a --archlist, repoquery
> and
>  > yumdownloader both do for instance. This is more for looking at data on
>  > ppc from an i386 box, as i386 is already in the archlist for x86_64.
>    ^^^
>  
>  You meant x86_64 here, I think.  I noticed that switch and noticed that it
>  didn't help for this case. 
 No, I meant ppc. Normally yum would see ppc packages, when on an x86_64
machine and "know" that it can't use them ... so will auto exclude them.
--archlist changes that.

>  >  And that doesn't change what $basearch will be in the
> config. files
>  > because doing that is a really bad idea due to the fact that you'll have
>  > changed what /var/cache/yum/blah/ points to without the next run of yum
>  > knowing (it's a bad idea to have the same repoid point to more than one
>  > place).
>  
>  Right, I figured that would be the gotcha with what I had in mind.
>  Maybe it would make sense for yum to name its cache subdirs repo.basearch?
>  
>  >  So what you probably want is to create a blah-i386 to go with your
>  > normal blah repo. ... which hardcodes i386 as the arch. Leave it
>  > disabled, and then whever you want to use it do:
>  
>  It seems like a simple enough change to use basearch in the cache dir
>  names.  Then everyone could do this for all the repos without fiddling with
>  repo configs.  Does that seem like something yum could do in the future?
>  (I'm not asking for any of this to be done next week or anything.)
>  
>  Maybe also --repoid et al could grok "reponame.arch" syntax (akin to the
>  package "name.arch" syntax you can use).  Another way to state it is that
>  the full "repoid" would be "reponame.arch", and "reponame"
> alone turns into
>  "reponame.$basearch" implicitly. 
 We've recently changed upstream yum so that the base cachedir can
contain variables. Ie. instead of:

cachedir = /var/cache/yum

...you can do:

cachedir = /var/cache/yum/$basearch/$releasever

...this solves a couple of problems over using the repo.arch syntax.
Having a command line option to change arch/releasever is another
challenge, for a couple of reasons.
 Although x86_64 => i386 there is an easy way, as you can (after the
above change) do:

setarch i386 yum blah

...and it'll have it's own cachedir.

-- 
James Antill <james(a)fedoraproject.org&gt;
Fedora