Bug 538526 – virtual/libudev should depend on >=sys-fs/udev-208 instead of >=sys-fs/udev-208-r1

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Robert Sharp 2015-02-02 11:33:01 UTC]

I had a nightmare trying to install the trivial hal-flash package and finding eudev slated for installation but (fortunately) blocked by the system default udev. Turned out the root cause of the problem is the assumption in the virtual/libudev (etc) that the baseline for udev is 208-r1 and I had just 208. I fixed the problem by manually upgrading udev to 208-r1 but it seemed nonsensical to me not to recognise my udev version and assume I wanted eudev instead.

Which leads me to probably the real reason I am raising this bug - I do not think that the udev/systemd/eudev "compromise" is clearly documented or well managed within portage. I am using the default set up (openrc/udev/sysvinit) so I do not expect to find eudev anywhere, but equally there does not seem to be a clear and unambiguous way of declaring that this is what I want (I sort of expected an eudev use flag). This "bug" is a case in point: if the user hasn't got >=208-r1 then he must want eudev. No?

I want to stick with 208 please but why no slot? Surely that would be easier if you are deliberately keeping a 208 stream going, which seems to be the case.

I found a really good explanation of this confusing situation on a mailist archive (http://www.gossamer-threads.com/lists/gentoo/amd64/284975) but nothing like this on our own Wiki. In fact there is no mention of any of the issues around udev/eudev at all on the wiki. I would be happy to add something but I think someone else might be better placed to do so?

[Comment 1 Jeroen Roovers (RETIRED) 2015-02-02 11:51:04 UTC]

1) This doesn't look like you're reporting a bug.
2) You can actually edit the wiki.
3) sys-fs/udev-2.0.8 was removed on June 2 2014.

[Comment 2 Robert Sharp 2015-02-02 13:21:40 UTC]

The bug I am reporting is in virtual/libudev (libudev-215-r1.ebuild) where:

>=sys-fs/udev-208-r1:0/0[${MULTILIB_USEDEP},static-libs?]

which should read:

>=sys-fs/udev-208:0/0[${MULTILIB_USEDEP},static-libs?]

As I understand it, 208 -> 208-r1 should not have involved any material change so why assume that a system with udev-208 is a system with no udev at all? Yes, udev-208 may have been removed from the current system, by why should that invalidate anyone who has yet to upgrade from 208 to 208-r1? Is there something about 208-r1 that is fundamentally different to 208? In which case, why is it only an r1 on 208?

The net effect of this problem is that a simple emerge of a simple package attempted to completely change my fundamental (and default) selection of udev. At the very least, why does libudev (and its friends) assume eudev is the default if it thinks (erroneously) that udev is not installed (swap entries around in ebuild?)

I know I can update the wiki, and I can if no-one else will, but I am not an expert in these matters and surely it would be better if someone who is did the writing?

[Comment 3 Jeroen Roovers (RETIRED) 2015-02-02 13:50:18 UTC]

(In reply to Robert Sharp from comment #2)
> The bug I am reporting is in virtual/libudev (libudev-215-r1.ebuild) where:
> 
> >=sys-fs/udev-208-r1:0/0[${MULTILIB_USEDEP},static-libs?]
> 
> which should read:
> 
> >=sys-fs/udev-208:0/0[${MULTILIB_USEDEP},static-libs?]

That doesn't make a single difference.

[Comment 4 Robert Sharp 2015-02-02 13:56:20 UTC]

I disagree.

As I already stated, I had udev-208 installed and virtual/libudev assumes, because of this line, that I did not have udev installed AT ALL and therefore attempted to install eudev instead. If it had been as I proposed then it would not have done this but would have recognised that I had udev installed. I updated udev 208 manually to 208-r1 and everything was fine but it took me a long time to work out that this was the issue, given I was actually doing something that had nothing to do with udev directly.

[Comment 5 Jeroen Roovers (RETIRED) 2015-02-02 14:32:41 UTC]

(In reply to Robert Sharp from comment #4)
> I disagree.

[Comment 6 Robert Sharp 2015-02-02 14:34:08 UTC]

Thanks for your help.