Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 444398 - virtual/udev
Summary: virtual/udev
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal enhancement with 1 vote (vote)
Assignee: udev maintainers
URL:
Whiteboard:
Keywords: Goal
Depends on:
Blocks: 437570
  Show dependency tree
 
Reported: 2012-11-23 07:41 UTC by Richard Yao (RETIRED)
Modified: 2012-12-02 23:49 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Yao (RETIRED) gentoo-dev 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) gentoo-dev 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>udev-bugs@gentoo.org</maintainer> to metadata.xml of the virtual

And you are done. Have at it.
Comment 2 Ian Stakenvicius (RETIRED) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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.