Subject: eudev: Undeclared conflict

From: Mark Hindley <[email-masked]>
Date: Sat, 14 Dec 2024 22:11:47 +0000

Package: eudev
Version: 3.2.14-2
Severity: normal
Control: affects -1 mdadm

Boian,

eudev has and undeclared file conflict with systemd-dev:

Unpacking eudev (3.2.14-2) ...
dpkg: error processing archive /var/cache/apt/archives/eudev_3.2.14-2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/pkgconfig/udev.pc', which is also in package systemd-dev 257-2

I suppose it needs a Conflicts, but that needs testing to ensure that
build-depends we require are still co-installable. I came across this while
debugging mdadm autopkgtest failures.

Mark.

---

From: Boian Bonev <[email-masked]>
Date: Thu, 24 Apr 2025 14:43:24 +0300

I see no reason whatsoever for eudev to ship development files
(usr/share/pkgconfig/udev.pc).

Moving that file to libeudev-dev seems the proper way to go, and adding
"libeudev-dev breaks eudev" to be able to install in the proper order
and "libeudev-dev breaks systemd-dev" for avoiding co-installing
libeudev-dev and systemd-dev. Or maybe it is better to convert the last
one to conflict?

The part that I didn't verify is how the packages that require udev.pc
are declaring that dependency - I am afraid currently it is a side
effect of something else transitively pulling in eudev.

With best regards,
b.

---

From: Mark Hindley <[email-masked]>
Date: Thu, 24 Apr 2025 18:59:47 +0100

Hi,

> effect of something else transitively pulling in eudev.

Yes, this is the less certain part. For forked sources the B-D can be
adjusted. For unforked they might use systemd-dev. So long as systemd-dev, eudev
and libeudev1 remain coinstallable, I think it is all OK.

It would be good to find a concrete example to check my thought experiment.

Mark

---

From: Mark Hindley <[email-masked]>
Date: Sat, 26 Apr 2025 07:40:24 +0100

Hi,

One further thing, the compiled udev.pc still contains an aliased path:

 udev_dir=/lib/udev

Mark

---

From: Mark Hindley <[email-masked]>
Date: Sat, 26 Apr 2025 08:22:51 +0100

> One further thing, the compiled udev.pc still contains an aliased path:

Sorry, this was perhaps a bit cryptic. This was with your current git HEAD.

Mark

---

From: Mark Hindley <[email-masked]>
Date: Tue, 6 May 2025 11:13:08 +0100

> One further thing, the compiled udev.pc still contains an aliased path:

I had a quick look at this. There is a quick hack just to edit
src/udev/udev.pc.in, but it isn't really 'correct'

udev_dir is set from $udevlibexecdir and that from $rootlibexecdir, but the
handling of configure --with-rootlibexecdir appears broken.

Can you have a look?

Thanks

Mark