Re: [RFC] BC breakage in PEAR - how to handle it properly

On Thursday, September 18, 2003 7:22, Greg Beaver wrote: > Marshall Roch wrote: >> Greg Beaver wrote: >> >>> Problem: >>> BC breakage in PEAR has not been addressed. If one package depends on >>> version 2.x of a package, and another depends on version 1.x, one >>> package loses in the end. version 1.x can't be installed with version >>> 2.x. >> >> >> Just out of curiosity, how does CPAN (or other similar projects) handle >> this, and does it have any major problems? > A look at CPAN's docs for developers doesn't mention any restrictions on > version aside from properly using the $VERSION variable at the start of > your files. A peek at DBI's package page describes changes from an > earlier version, and it looks like BC is an individual author's choice. > Their only recommendation is to update source often to get bugfixes. > It might be good to check out debian and perhaps RedHat rpm to see what > they do. My experience with them is that dependencies are > version-specific (future dependencies are not allowed at all) They simply upgrade the software to work with the new versions. Ie. if a new version of glibc appears, they patch all the packages to work with this new version. Sometimes when that can't be done, they do different things: compat packages: compat-libstdc++-6.2-2.9.0.16 libstdc++-2.96-110 sepparate packages: libglade-0.17-5 libglade2-1.99.9-2 qt-3.1.1-6.i386.rpm qt2-2.3.1-13.i386.rpm sepparate packages with version restrictions: db1-1.85-8 db3x-3.2.9-4 db2-2.4.14-10 db3-3.3.11-6 libxml-1.8.17-3 libxml2-2.5.7-1 glib-1.2.10-5 glib2-2.0.1-2 (these examples looks like versions of packages with major version change, starts from that major version (db2-2.4, db3-3.3), that a good idea for avoiding confusing) -- Tomas V.V.Cox mailto:cox@idecnet.com