On Wed, Jul 11, 2012 at 2:26 PM, Thomas Sachau <to...@gentoo.org> wrote: > Michał Górny schrieb: >> On Tue, 10 Jul 2012 21:23:39 +0200 >> Thomas Sachau <to...@gentoo.org> wrote: >> >>> Michał Górny schrieb: >>>> Hello, all. >>>> >>>> Since nowadays udev is bundled within systemd, we start having two >>>> libudev providers: >=sys-apps/systemd-185 and sys-fs/udev. Making >>>> the long story short, I would like to introduce a virtual for >>>> libudev which would pull in either of those two. >>>> >>>> There are three USE flags used in conditionals when depending on >>>> udev: >>>> - gudev - for glib wrapper on udev, >>>> - hwdb - to pull in hwids, >>>> - static-libs. >>>> >>>> The former two were previously provided by 'extras' USE flag, >>>> and the third was unconditional. >>>> >>>> I'm attaching an example virtual/libudev which does the job. Sadly, >>>> because of the 'extras' compatibility it's a big ugly conditional. >>>> >>>> An alternative would be to provide separate virtual/libudev >>>> and virtual/libgudev; and maybe changing ebuilds not to depend on >>>> [hwids] but rather pull in sys-apps/hwids directly (since that's >>>> what the flag does). >>>> >>>> What are you thoughts? >>> >>> As discussed on IRC, there is still no consensus for installing the >>> udev files with systemd, which is the beginning for the block and the >>> virtual. So we should first sort that point out, before we even start >>> to think about an ebuild for an udev virtual. >> >> Do you have a technical or policy reason prohibiting me from maintaining >> a systemd ebuild following the upstream policies? > > How about this simple one: The udev ebuild does already install udev, so > why should we have another package also installing the same thing, > resulting in a blocker, the need to switch from one package to another > and the need for package maintainers to switch their dependencies?
Just to put a number to this, there are currently 126 packages in the tree with a dependency on sys-fs/udev. > Since William already said, that he will move the udev installation to > /usr/lib, i dont see any technical reason left to not simply depend on > the udev ebuild. > And if you fear issues about not knowing which parts to install, then > just check the files installed by the udev ebuild, remove them from your > systemd ebuild and you are done. This means that systemd users end up building the udev components twice, and throwing away the second copy. You don't seem to care about this, but I think it is a valid concern. I am guessing that systemd is or will become very sensitive to any change in udev's API, so each systemd version would have to depend exactly on the corresponding udev version. This means that a systemd version bump could be stuck waiting on the corresponding udev version. I also wonder if incompatibilities may be introduced by passing different build options in the udev and systemd ebuilds due to having different use flags enabled, for example. This can be worked around with use-deps of course, but it is yet another pain point for the systemd maintainer. If there were a way to tell the systemd build system to build against the "system udev", that might avoid the issue, but I doubt systemd upstream would implement such a thing. Personally, I think a consolidated systemd/udev package is the best way to go here. Short of that, the virtual + blockers seems like an acceptable solution.
