-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ming Hua wrote: > On Sun, Oct 08, 2006 at 11:14:51PM +0200, Székelyi Szabolcs wrote: >> Hi, >> >> Ming Hua wrote: >>> On Fri, Oct 06, 2006 at 01:10:32AM +0200, Székelyi Szabolcs wrote: >>>> James Westby wrote: >>>> >>>>> * Do you need Replaces: libvrb-dev as well? >>>> I have seen similar (ie. development) packages with and others without >>>> this. Do I? >>> If you want to support upgrading for users who use you previous >>> unofficial package, and libvrb0-dev ships the same files as libvrb-dev, >>> then yes, you need Replaces: (and probably also Conflicts:) libvrb-dev. >> There is no libvrb-dev package. It is a virtual package to ensure that >> only one development version is installed at a time (Provides + Conflicts). > > I see. Didn't notice libvrb0-dev Provides libvrb-dev before, sorry. > >>> I know the naming of -dev packages is a >>> very controversial topic, so I want to hear your (and other people's) >>> opinion. >> The soversion is usually added to the -dev package name to be able to >> support multiple versions of a library off-line, which means all >> versions can be found in the archive, but only one can be installed on >> the user's machine. > > I think what I really wanted to ask is what would be a good reason to > have multiple versions of a library avaiable in the archive. The > package I maintain, scim, changes its SONAME once in a while, but keeps > API compatible all the way,
What if it doesn't? All dependent packages will suddenly FTBFS. You can say that it's the responsibility of upstream to maintain interface compatibility, or rename the headers if they can't. But from our point of view, it's better to be on the safe side. It's a bit similar to the well-known saying among engineers, "Be liberal in what you accept, be conservative in what you send.". Supporting multiple versions in the archive makes us liberal in what we accept, allowing upstream to make the mistake of not renaming header files. > so I only keep one -dev package, without > the SONAME. > > My impression is that if you make both libfoo0-dev and libfoo1-dev > provide and conflict libfoo-dev, you are implying that porting a package > building against libfoo0 to building against libfoo1 should be zero or > minimal effort. I'm implying just the opposite. libfoo-dev is just a tool to ensure that only one libfooX-dev is installed. This way there is no need to enumerate all libfooX-dev packages in the Conflicts field of all of them. Look at libcupsys2-dev: Conflicts: libcupsys1-dev, libcupsys-dev, cupsys (<< 1.1.22-3) If libcupsys1-dev Provided libcupsys-dev, then libcupsys1-dev could have been left out of this list. The problem with this is that it doesn't scale with the maturity of the package. libfoo53-dev should list libfoo0-dev, libfoo1-dev, libfoo2-dev, ..., libfoo52-dev in its Conflicts field. But if all of them Provides libfoo-dev, then it is enough for libfoo53-dev to Conflict with the single virtual package libfoo-dev (among possible other conflicts, of course). Keeping more versions of the development package enables building all other packages using different (so)versions of the library, while keeping just one may work for building some packages, but may break others if the two versions are not API compatible. > If that's the case, isn't keeping only one -dev package > a better choice, if just to encourage other packages to migrate to the > newer version of the library? We can't force upstream to switch to the new interface version. If they decide to use the previous version of the library for some time, their software may FTBFS. I don't want to (even temporarily) kick other packages from the archive just because they don't/can't use the newest API. >> The question is, which mechanism should be used to >> accomplish this? Do we need Replaces:? I think Provides and Conflicts is >> enough. > > The Debian Library Packaging Guide (written by Junichi Uekawa, mentioned > by a lot of DDs, but AFAIK is still an unofficial guide) seems to agree > with you: But I don't agree with myself. ;) If libfoo0-dev and libfoo1-dev both contain foo.h, then at least one of them must Replace the other(s). Again, it's the same with Conflicts, it's easier to accomplish this using virtual packages. Thanks for your remarks, - -- Szabolcs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLrdVGJRwVVqzMkMRAmo+AKCGrkGMck2FbwdfBIrODXsZ95+q+QCcDFsB NVN0+k2FEeevb33Xruqa1IA= =0F3h -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
