Re: naming and relationships of development packages
-----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-----
Reply to: