On Mon, Mar 08, 2004 at 09:22:36PM +0100, Stefan van der Eijk wrote: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.
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?
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 :-(
I've tried on the rpm list noted on rpm.org, but I've had little / no response.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'm expecting some resistance against change. This is always the case. :-/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.
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.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.
In this case you will probably be able to choose the internal namingIndeed. This was my objective, to make it completely independant from existing naming, and completely based on a capability a package provides and / or requires.
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?
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
