Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1036085: Please drop Conflicts/Replaces with dhcp-client

100 views
Skip to first unread message

Shengjing Zhu

unread,
May 15, 2023, 3:50:07 AM5/15/23
to
Package: dhcpcd-base
Version: 9.4.1-21
Severity: normal
X-Debbugs-Cc: zh...@debian.org

It seems you add this because:

commit 37b4b03f4d5e598eb2a3b0a58c6eec269b09c585

Add more Conflicts with other DHCP clients

interfaces(5) precedence for DHCP method is: dhclient, pump, udhcpc, dhcpcd.

We wanna ensure that none of those with a higher priority are installed.
We skip pump since it hasn't been in the Debian archive for a long time.

However IMO it looks like misuse of Conflicts/Replaces. For example there are
not conflict files between isc-dhcp-client and dhcpcd-base, but now they can't
be installed together.
Yes, people don't need to install two different dhcp clients. But they should
have the ability to install them together as long as they don't have real
conflicts (same file for example).

Copying our policy 7.4:

Neither Breaks nor Conflicts should be used unless two packages cannot be
installed at the same time or installing them both causes one of them to be
broken or unusable. Having similar functionality or performing the same tasks
as another package is not sufficient reason to declare Breaks or Conflicts with that package.

https://www.debian.org/doc/debian-policy/ch-relationships.html

I come across this issue since I find this package's autopkgtest can't be run
on Ubuntu. Because their base system has isc-dhcp-client installed (needed by
ubuntu-minimal package, which can't be removed).

Please remove the Conflicts/Replaces with dhcp-client. (No urgent for Bookworm
release, but a new upload to experimental first is much appreciated)

Thanks.

Martin-Éric Racine

unread,
May 15, 2023, 4:12:20 AM5/15/23
to
On Mon, May 15, 2023 at 10:42 AM Shengjing Zhu <zh...@debian.org> wrote:
> Copying our policy 7.4:
>
> Neither Breaks nor Conflicts should be used unless two packages cannot be
> installed at the same time or installing them both causes one of them to be
> broken or unusable. Having similar functionality or performing the same tasks
> as another package is not sufficient reason to declare Breaks or Conflicts with that package.

The Conflicts/Provides isn't there because they provide similar
features. It is there because the backend has no way of selecting
which DHCP client will be used. This is a case similar to sendmail.

> I come across this issue since I find this package's autopkgtest can't be run
> on Ubuntu. Because their base system has isc-dhcp-client installed (needed by
> ubuntu-minimal package, which can't be removed).

This is what needs to be fixed. ubuntu-minimal needs to Depends on
"isc-dhcp-client | dhcp-client".

Martin-Éric

Shengjing Zhu

unread,
May 15, 2023, 4:30:05 AM5/15/23
to
On Mon, May 15, 2023 at 4:05 PM Martin-Éric Racine
<martin-er...@iki.fi> wrote:
>
> On Mon, May 15, 2023 at 10:42 AM Shengjing Zhu <zh...@debian.org> wrote:
> > Copying our policy 7.4:
> >
> > Neither Breaks nor Conflicts should be used unless two packages cannot be
> > installed at the same time or installing them both causes one of them to be
> > broken or unusable. Having similar functionality or performing the same tasks
> > as another package is not sufficient reason to declare Breaks or Conflicts with that package.
>
> The Conflicts/Provides isn't there because they provide similar
> features. It is there because the backend has no way of selecting
> which DHCP client will be used.
>

But they can be installed together right? then it falls into the
policy that Breaks/Conflicts is not the right place.

People can just uninstall other clients manually to let the ifupdown
to choose the wanted backend.
It may have weird use cases like, using different implementations of
dhcp client for different hardware interfaces. I believe the policy is
there to not restrict the usefulness of different implementations.

> This is a case similar to sendmail.

I don't think so. The mail-transport-agent packages both ship
/usr/sbin/sendmail file. This is allowed and suggested by the policy
to use Conflicts/Replaces.

--
Shengjing Zhu
0 new messages