[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Package Build Report - Fedora Extras Development



On Fri, 2005-05-06 at 04:29 +0200, Ralf Corsepius wrote:
> On Thu, 2005-05-05 at 17:09 -0400, Jeremy Katz wrote:
> > On Thu, 2005-05-05 at 21:52 +0200, Ralf Corsepius wrote:
> > > Urgh, in other words, SONAME provides have become meaningless and
> > > useless, i.e. rpm on x86-64 is severely borked :(
> > 
> > No, because the soname provides/requires are auto-generated -- if you
> > ever manually put
> >   Requires: libfoo.so.1
> > in a spec file, then you are doing something wrong.
> 
> What? It is prohibited to use autogenerated virtual provides in
> rpm.specs?

The provides are auto-generated based on elf headers; they get used by
the auto-generated requires which also look at the elf headers.  These
two are consistent in how they do things.  Listing it in a specfile is
_always_ going to require an ifarch hack, and realistically, a
requirement like this should get picked up by the auto-generated
requires.  If it's not, then you have a bug in your package.

They're autogenerated and thus semantics are subject to change.
Granted, they haven't changed in ... a long time.  The
libfoo.so.1(64bit) has been being done on all 64bit platforms[1] since
the dawn of time.

How else do you want to differentiate between a provide of the 32bit
libfoo.so.1 and the 64bit one?  

> Show me the piece of documentation where
> a) the semantics of *.so.xx provides/requires is documented

Maximum RPM and the Red Hat RPM Guide both provide a start at this.  If
you want the gory details, take a look at rpm/build/rpmfc.c (or
alternately, the no longer generally used
rpm/autodeps/linux.{req,prov}).  If you really want me to go into it, I
will, but it won't be pretty ;-)  Note that the (64bit) markers have
been being added on 64-bit platforms[1] essentially forever on Linux
just to handle the question I ask about differentiation above.

> b) it is documented that using autogenerated virtual provides in
> manually written dependencies is prohibited.

I think that Maximum RPM pretty clearly shows that you should be doing
names of packages (or something that's explicitly listed as Provides:
bar in another package's specfile).  Also, the Red Hat RPM Guide calls
it out more explicitly in Chapter 11.

Jeremy

[1] With the exception of alpha.  But some might argue it predates
forever ;-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]