Automatic BuildRequires; platform independent specfiles

Tue Mar 9 22:32:15 UTC 2004

Axel Thimm wrote:

>On Mon, Mar 08, 2004 at 09:22:36PM +0100, Stefan van der Eijk wrote:
>  
>
>>I've been advocating getting the right BuildRequires into the src.rpm 
>>packages:
>>   http://qa.mandrakesoft.com/twiki/bin/view/Main/BuildRequires
>>
>>Due to the fact that -devel packages have no *automatic* dependencies 
>>added to them, there is no significant dependency structure in them. 
>>This makes getting the right BuildRequires for the packages nearly 
>>impossible. This issue and the solution Mandrake chose to implement are 
>>documented here:
>>   http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmDevelDependencies
>>    
>>
>
>This is very interesting stuff, especially deriving the recursive
>-devel dependencies that way.
>
>Is there a tool which can be used right away to generate these
>Provides/Requires hooks? Does the Mandrake rpm carry such patches?
>  
>
Yes. Mandrake implemented option 3. The exact code from the Mandrake 
find-provides and find-requires are on the page (Implementation 
examples), with the version number of the mandrake rpm package it was 
taken from. It may have changed in later releases of the rpm package.

Here's and example on how the dependencies are implemented on the package:

# rpm -qpR libpng3-devel-1.2.5-10mdk.alpha.rpm | sort -u
bash 
*devel(libm(64bit)) 
devel(libz(64bit))  *
libpng3 = 2:1.2.5-10mdk
pkgconfig 
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
zlib-devel

# rpm -qp --provides libpng3-devel-1.2.5-10mdk.alpha.rpm | sort -u
*devel(libpng(64bit)) 
devel(libpng12(64bit)) 
*libpng-devel = 2:1.2.5-10mdk
libpng3-devel = 2:1.2.5-10mdk
png-devel = 2:1.2.5-10mdk

As you can see the "zlib-devel" requires is redundant, since 
"devel(libz(64bit))" already pulls it in.

The things we learned at Mandrakesoft when implementing this:
- Do it quickly, put a team on it to rebuild all the packages affected 
against the new find-provides and find-requires scripts. If you don't do 
it quickly the distro will be broken, as packages will be asking for 
dependencies that aren't provided yet. At Mandrake we had quite some 
resistance against the new scheme, users that didn't understand what it 
brought and only saw the downside during the transition became quite vocal.
- Choose the same naming scheme as Mandrake "devel(libname)" for 32bit 
libs, "devel(libname(64bit))" for 64bit systems. At Mandrake we first 
used "libname.so" like dependencies, but some of these were already 
being provided by some packages. The libdb3.3-devel package being the 
perfect example on where it went wrong. Mandrake ended up making the 
transition twice :-(

>>Esspecially with the RpmDevelDependencies I think all distributions 
>>would benefit from this, perhaps we can try to make it part of a 
>>cross-distro rpm naming standard.
>>    
>>
>
>Yes! :)
>
>But this is probably the wrong list to address these issues. There is
>an rpm-devel list (http://rpm-devel.colug.net/, Cced) where embedding
>of these Provides/Requires hooks could be discussed. 
>
I've tried on the rpm list noted on rpm.org, but I've had little / no 
response.

>There is also a
>packaging list (http://www.freestandards.org/cgi-bin/mailman/listinfo/packaging),
>which would look appropriate for such a discussion, but it looks quite
>silent in the last year.
>
>As for the common naming issue, you will get into serious trouble
>convincing all parties.
>
I'm expecting some resistance against change. This is always the case. :-/

>It has been tough to discuss this within the
>Red Hat community, so adding Mandrake and SuSE will certainly not make
>it easier ;)
>
>Unless the external name is independent of the internal
>Provides/Requires hooks, so that Red Hat can continue calling
>zlib{-devel} that way etc., and some small monolithic packages can
>remain monolithic and need not be split into devel/lib etc.
>  
>
For this scheme the external name can remain unchanged. What I'm 
actually aiming on is to make more of a distros dependencies consist out 
of automatically generated dependencies (conforming to a cross-distro 
naming standard) so that the external names aren't loose their 
importance. What's really important is the *capability* a package 
provides or requires, the external name is of less importance.

>In this case you will probably be able to choose the internal naming
>convention yourself, nobody would object. It seems that your scheme is
>indeed independent of the external names and splitting of
>sub-packages, isn't it?
>  
>
Indeed. This was my objective, to make it completely independant from 
existing naming, and completely based on a capability a package provides 
and / or requires.

>Writing cross-distro specfiles! I am looking forward to that day! :)
>  
>
This day isn't that far away. I think many people are looking forward to 
it. I'm also involved with plf (plf.zarb.org) and the plf would also 
love to make fedora packages. Issue at the moment is that the lack of 
standardisation is making this difficult.

regards,

Stefan van der Eijk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3403 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20040309/2937001f/attachment.bin>