[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: naming and relationships of development packages

Hash: SHA1

Florent Rougon wrote:
> Székelyi Szabolcs <cc@mail.3d.hu> wrote:
>> 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.
> I didn't say it's needed. I even posted an experiment showing that with
> the tools from unstable, it makes no difference in:
>   apt-get -s install <virtual package>
>> 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.
> It shows that, even when not using Replaces, things do work in this
> situation.

You are absolutely right, but that's not what the thread was about.

>> But the question is: is Replaces needed to get the previous version
>> removed upon installation of the new package?
> What previous version are you talking about? Which "new package"?

Installing libfoo1-dev when libfoo0-dev is already installed. The
original thread was about the need for "Replaces: libfoo-dev" among the
control fields of libfoo0-dev and libfoo1-dev. In this case the "new
package" is libfoo1-dev.

I think you misunderstood the topic of the thread. We are talking about
two different things. Sorry if this is because of my poor composition.

>> 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.
> So, it's right because dpkg doesn't complain when the user it shooting
> itself in the foot? If the user uses --force-conflicts, he is on its
> own.

Agreed. I would add that if we can, we should minimize the impact of a
"power" user. That's what I'm trying to do. It's not about dpkg not
complaining, it's about dpkg not failing because of "trying to overwrite
foo.h which is also in package libfoo0-dev" (or something similar).

>> I disagree. Provides is used for that. It has nothing to do with Replaces.
> Fine. I tried to explain how the use of Replaces in the MTA example
> could be justified with the information given in Policy. If that is not
> enough for you, go argue with the Policy maintainers.

I won't. I understand the role of Replaces now. If a package contains
files those are contained in another package also, then Replaces must be
used. That's the simple rule. And if foo.h is contained in libfoo0-dev
and libfoo1-dev, then they should replace each other. An easy and
extensible way of doing this is make them Provide the libfoo-dev virtual
package and make them Conflict with libfoo-dev also, meaning "all other
versions". Thus only one version will be installed.

Thanks for your comments anyway.

- --

Version: GnuPG v1.4.5 (GNU/Linux)


Reply to: