Bug 444398 – virtual/udev

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Richard Yao (RETIRED) 2012-11-23 07:41:02 UTC]

We need virtual/udev for proper dependency resolution when sys-fs/eudev enters the tree. This affects systemd (and the brain-damaged fork should anyone volunteer to maintain it).

Does anyone have any thoughts on what the right way to implement this would be? Also, who would maintain it?

[Comment 1 Samuli Suominen (RETIRED) 2012-11-23 10:16:09 UTC]

- Move udev, eudev, systemd (in this order) from virtual/dev-manager to virtual/udev

- Put virtual/udev to virtual/dev-manager as a provider

- Create USE flags in the virtual so that they match USE flags of the udev ebuild so apps can depend on them: "acl", "gudev", "hwdb", "introspection", "keymap", "openrc", "selinux", "static-libs" (as per udev-9999.ebuild currently in tree while writing this)

- Put <herd>udev</herd> <maintainer>[e-mail]</maintainer> to metadata.xml of the virtual

And you are done. Have at it.

[Comment 2 Ian Stakenvicius (RETIRED) 2012-11-23 14:05:33 UTC]

Sounds good!  

Quick questions though:

The proposal from earlier in the year was for a 'virtual/libudev' that would be in addition to 'virtual/dev-manager', assumingly to only virtualize direct dependencies on udev (for libudev and whatnot) rather than a dependency on a dev-manager in general.  Is there any advantage to the virtual/libudev idea that the proposed virtual/udev might not provide?  I can't think of any, but I'd appreciate at least a couple of other opinions on it.

[Comment 3 Richard Yao (RETIRED) 2012-11-23 23:21:18 UTC]

A concern of mine is providing a smooth upgrade path for older systems that have outdated versions of udev.

Perhaps we could have virtual/udev-0 for packages that can use libudev.so.0 and virtual/udev-1 for packages that require libudev.so.1. That way the dependency in packages that are not backward compatible would become >=virtual/udev-1 while all other packages could use virtual/udev. That should permit portage's dependency resolver to handle upgrades gracefully.

Does anyone have any objections?

[Comment 4 Richard Yao (RETIRED) 2012-11-23 23:24:14 UTC]

(In reply to comment #2)
> Sounds good!  
> 
> Quick questions though:
> 
> The proposal from earlier in the year was for a 'virtual/libudev' that would
> be in addition to 'virtual/dev-manager', assumingly to only virtualize
> direct dependencies on udev (for libudev and whatnot) rather than a
> dependency on a dev-manager in general.  Is there any advantage to the
> virtual/libudev idea that the proposed virtual/udev might not provide?  I
> can't think of any, but I'd appreciate at least a couple of other opinions
> on it.

This was one of the things that was on my mind when I asked for thoughts. So far, it appears that all packages that used libudev.so.0 can be recompiled against libudev.so.1, Unless we discover something that contradicts that, there should be no point to having virtual/libudev.

[Comment 5 Samuli Suominen (RETIRED) 2012-11-24 17:52:20 UTC]

It's done

[Comment 6 consus 2012-11-25 15:25:25 UTC]

(In reply to comment #0)
> anyone volunteer to maintain it

I can maintain it.

[Comment 7 Richard Yao (RETIRED) 2012-11-26 17:49:02 UTC]

(In reply to comment #6)
> (In reply to comment #0)
> > anyone volunteer to maintain it
> 
> I can maintain it.

Thanks for volunteering, but I am afraid that this is not something that people would proxy maintain. My question was meant to ask which of the groups of Gentoo developers affected by this would maintain it. In particular, the current udev maintainers, base system, eudev or systemd.