Re: naming and relationships of development packages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Florent Rougon wrote:
> Székelyi Szabolcs <cc@mail.3d.hu> wrote:
>> 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. The question is, which mechanism should be used to
>> accomplish this? Do we need Replaces:? I think Provides and Conflicts is
>> enough.
>
> I think it's an analogous case to that of the MTA in Policy, and
> therefore, that Replaces should be used.
That's right. But why is Replaces needed in the case of an MTA? If a
package Providing mail-transport-agent is installed, and the user is
about to explicitly install another package which also Provides and
Conflicts with mail-transport-agent, then the currently installed
package will be removed anyway before the new one is installed. I do not
see the need for Replaces.
> However, I'm not sure whether
> any of our current tools (apt, dpkg, etc.) makes any difference if it is
> used or not, in this context.
>
> Actually, I tested one case with the apt from unstable:
>
> apt-get -s install <virtual package>
>
> Having the Replaces in addition to the Provides and Conflicts made no
> difference:
>
> foo 1.0-4
> ~~~~~~~~~
> Provides: foo-pkg
> Conflicts: foo-pkg
>
> # apt-get -s install foo-pkg
> Reading package lists... Done
> Building dependency tree... Done
> Note, selecting foo instead of foo-pkg
> The following NEW packages will be installed:
> foo
> 0 upgraded, 1 newly installed, 0 to remove and 240 not upgraded.
> Inst foo (1.0-4 Florent Rougon's packages for experiments:unstable)
> Conf foo (1.0-4 Florent Rougon's packages for experiments:unstable)
>
> foo 1.0-5
> ~~~~~~~~~
> Provides: foo-pkg
> Conflicts: foo-pkg
> Replaces: foo-pkg
>
> # apt-get -s install foo-pkg
> Reading package lists... Done
> Building dependency tree... Done
> Note, selecting foo instead of foo-pkg
> The following NEW packages will be installed:
> foo
> 0 upgraded, 1 newly installed, 0 to remove and 240 not upgraded.
> Inst foo (1.0-5 Florent Rougon's packages for experiments:unstable)
> Conf foo (1.0-5 Florent Rougon's packages for experiments:unstable)
But that's not right. With this, what you've tested is installing the
virtual package installs the real package instead. That's the way it
should be.
But the question is: is Replaces needed to get the previous version
removed upon installation of the new package?
After an hour of experimentation, it turned out that
* dpkg *will not* automatically remove the old package regardless of
the presence of the Replaces field
* apt *will* remove the old package regardless of the presence of the
Replaces field
which means that there is no need for Replaces to accomplish the above.
But...
What if the user forces the installation of the new package by
overriding the conflict (dpkg --force-conflicts)? Then Replaces can be
used to take over the files contained in both packages, so dpkg won't
complain about overwriting files which are contained in another package,
resulting in a somewhat more consistent installation.
According to this, I will add Replaces: libvrb-dev to libvrb0-dev.
> You can check how this situation is handled in the archive with the
> following command:
>
> grep-available -F Provides -s Package,Provides,Replaces,Conflicts \
> -e ".*-dev" | less
>
> You'll see that many packages use the Replaces, and many don't.
I smell mass bug filing... ;)
> Some even Replace and Conflict with the various -dev packages, but
> I don't think it's a good idea (Replacing and Conflicting with the
> virtual package should be enough):
>
> Package: libcupsys2-dev
> Provides: libcupsys-dev
> Replaces: libcupsys1-dev, libcupsys-dev, cupsys (<< 1.1.22-3)
> Conflicts: libcupsys1-dev, libcupsys-dev, cupsys (<< 1.1.22-3)
This is for historical reasons, I guess.
>> I'm not sure I understand the example about MTAs in Policy 7.5.2. Why is
>> Replaces needed at all in this particular case? Is this also valid in
>> the case of development packages? Why aren't Conflicts + Provides enough?
>
> Quoting § 7.5.2:
>
> Secondly, Replaces allows the packaging system to resolve which
> package should be removed when there is a conflict
>
> Based on that, I'd argue that the meaning of the Replaces in the MTA
> example is:
>
> Any real package providing mail-transport-agent should be favored upon
> the virtual package mail-transport-agent.
>
> i.e., if something pulls in mail-transport-agent for whatever reason
> (e.g., a dependency or 'apt-get install <virtual package>'), then in no
> case should the virtual package mail-transport-agent be installed; all
> other packages Replacing it are preferred to resolve the situation
> (which is fortunate, since of course, you cannot install a virtual
> package).
I disagree. Provides is used for that. It has nothing to do with Replaces.
Bye,
- --
Szabolcs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFLBokGJRwVVqzMkMRAhbUAJoDhhwX61lL5hltmzMznFoad8BkDACffW2b
N2GOkKtAIMVS98T8Ig4DMkU=
=rSgg
-----END PGP SIGNATURE-----
Reply to: