Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 348472 - break sys-fs/udev's "extras" use flag into acl, pci, usb
Summary: break sys-fs/udev's "extras" use flag into acl, pci, usb
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: udev maintainers
URL:
Whiteboard:
Keywords:
: 370197 (view as bug list)
Depends on: 370283 370285 370335 370339 370343 370347 370349 370351 370353 370359 370361 370377 370379 370381 370383 370385 370389 370393 370395 370397
Blocks:
  Show dependency tree
 
Reported: 2010-12-12 04:52 UTC by Matt Turner
Modified: 2011-07-31 01:08 UTC (History)
8 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 Matt Turner gentoo-dev 2010-12-12 04:52:11 UTC
If I've got USE="-acl" system-wide, I'd rather not have sys-apps/acl pulled in by one package if I can avoid it.

Packages on my system that depend on sys-fs/udev[extras]:

gnome-base/gvfs-1.6.6
net-wireless/bluez-4.69
sys-fs/udisks-1.0.1-r1
sys-power/upower-0.9.5
Comment 1 Daniel Pielmeier gentoo-dev 2010-12-12 11:14:16 UTC
FYI there was a discussion on gentoo-dev some time ago.

http://archives.gentoo.org/gentoo-dev/msg_c3d827863c64b6d144d21c97a2add380.xml
Comment 2 Matthias Schwarzott gentoo-dev 2011-04-30 10:57:43 UTC
latest udev-git contains a patch to split the extras switch. So we now can switch them individually. But do we want all of them to be use-flags?

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=d5d6a7f3040992f853eb23eb1bafac3b77891c2d

 
configure: allow to enable/disable extras individually
       - remove gobject introspection switch
       - disable hid2hci by default (moved to bluez)
       - disable action-modeswitch by default (will move to usb_modeswitch)
       - disable edd_id by default (problems with disk signatures)
       - disable legacy floppy by default (no more nasty device node hacks by default)
 
diff --git a/INSTALL b/INSTALL
 index 02ad55f..09dc3f7 100644 (file)
 
--- a/INSTALL
+++ b/INSTALL
@@ -27,9 +27,24 @@ All options:
   --with-selinux
       Link against SELinux libraries to set the expected context
       for created files.
-  --disable-extras
-      Disable the build of all extras which have larger external
-      dependencies like glib, libacl, libusb, ...
+  --disable-rule_generator
+      Disable persistent network, cdrom naming support.
+  --disable-hwdb
+      Disable hardware database support
+  --disable-udev_acl
+      Disable local user acl permissions support.
+  --disable-gudev
+      Disable Gobject libudev support.
+  --disable-keymap
+      Disable keymap fixup support.
+  --enable-floppy
+      Enable legacy floppy support.
+  --enable-edd
+      Enable disk edd support.
+  --enable-hid2hci
+      Enable bluetooth hid to hci switch.
+  --enable-action_modeswitch
+      Enable action modeswitch support.
 
 The options used in a RPM spec file usually look like:
   %configure \
Comment 3 William Hubbs gentoo-dev 2011-05-30 18:23:32 UTC
I would vote for having all options as separate use flags; especially
since we can set their default settings in IUSE.
Comment 4 Matthias Schwarzott gentoo-dev 2011-06-05 20:00:24 UTC
Added to udev-171.ebuild. If some use-flag names should be changed, please veto.
Comment 5 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-06-06 03:32:20 UTC
Note: the following in-tree packages must be updated for the new udev USE flags (and their maintainers need to be CCed on this bug):

app-misc/media-player-info
app-pda/synce-connector
dev-dotnet/gudev-sharp
dev-python/python-gudev
gnome-base/gvfs
gnome-extra/gnome-color-manager
media-gfx/shotwell
media-gfx/simple-scan
media-sound/pulseaudio
media-sound/rhythmbox
media-video/cheese
media-video/gxine
net-misc/modemmanager
net-misc/networkmanager
net-print/hplip
net-wireless/bluez
sys-fs/udisks
sys-power/upower
xfce-base/thunar
xfce-extra/thunar-volman

Ideally, until the more widely-installed of these packages (such as pulseaudio, networkmanager, upower, and gvfs) are fixed, udev with the new USE flags should be masked.
Comment 6 William Hubbs gentoo-dev 2011-06-06 05:48:20 UTC
(In reply to comment #5)
> Note: the following in-tree packages must be updated for the new udev USE flags
> (and their maintainers need to be CCed on this bug):

Actually, the better way to do this would be to make this bug into a tracker for all affected packages and open a bug for each of them.

It is late here for now, but I can start this process in a few hours after I get some sleep.

Regarding masking udev: I'm not sure whether that is a good idea, because once we start converting the packages, we will have to mask them as well until udev is unmasked.
Comment 7 Matthias Schwarzott gentoo-dev 2011-06-06 10:03:58 UTC
(In reply to comment #5)
> Note: the following in-tree packages must be updated for the new udev USE flags
> (and their maintainers need to be CCed on this bug):
> 
> app-misc/media-player-info
> [...]
> 
> Ideally, until the more widely-installed of these packages (such as pulseaudio,
> networkmanager, upower, and gvfs) are fixed, udev with the new USE flags should
> be masked.

Why should it be masked?
The only problem I can imagine is when some packages are converted to only depend on sys-fs/udev[gudev] and others only depend on sys-fs/udev[extras] so that portage cannot resolve this. Most likely the dependency should look like this (assuming the dependency is needed for gudev):
|| ( sys-fs/udev[gudev] sys-fs/udev[extras] )

If this is used, on systems where only on extras is depended the user gets <udev-171, else he gets udev-171.

Btw. is the depend on extras still required, or is sys-fs/udev itself enough now?
Comment 8 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-06-06 15:18:38 UTC
(In reply to comment #7)
> Why should it be masked?

Because of the limitations of portage's dependency-resolving algorithm. "emerge --update --deep --newuse world" first updated me to udev with the new USE flags, and the next time informed me of blocked packages.

> Btw. is the depend on extras still required, or is sys-fs/udev itself enough
now?

One cannot assume that "+" USE flags in dependencies are always turned on; it's a basic QA error. Packages currently depending on udev[extras] will have to be modified to alternatively depend on udev with the correct combination of new USE flags.
Comment 9 William Hubbs gentoo-dev 2011-06-06 15:44:08 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Why should it be masked?
> 
> Because of the limitations of portage's dependency-resolving algorithm. "emerge
> --update --deep --newuse world" first updated me to udev with the new USE
> flags, and the next time informed me of blocked packages.


That is because the packages haven't been updated as suggested in comment #7 yet.

> > Btw. is the depend on extras still required, or is sys-fs/udev itself enough
> now?
> 
> One cannot assume that "+" USE flags in dependencies are always turned on; it's
> a basic QA error.

I've never heard anyone in QA make this statement. The only ways a use flag with + set in IUSE will be turned off is if either the profile turns it off or a user does in make.conf or package.use.

> Packages currently depending on udev[extras] will have to be
> modified to alternatively depend on udev with the correct combination of new
> USE flags.

Yes, they will, but I also am not sure that I see that as a reason to mask udev.

I will speak with QA and see what they think.
Comment 10 William Hubbs gentoo-dev 2011-06-06 16:43:42 UTC
Another problem with hard masking udev in this situation is that there are systems which do not require udev with the extras use flag, and those systems should not be forced to wait for udev-171.
Comment 11 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-06-06 17:49:43 UTC
If you don't want to hard mask, then please release a higher revision of udev-171 with the old IUSE. For example, udev-171-r20 with old IUSE would work nicely, allowing you to maintain the ebuild with the new IUSE as udev-171-rN and with the old IUSE as udev-171-r2N. And it would allow everyone, including all the desktop users who use networkmanager and pulseaudio, to enjoy udev-171.

When the key packages that depend on udev[extras] have been fixed, you can release an ebuild with the new IUSE and an even higher revision number.
Comment 12 William Hubbs gentoo-dev 2011-06-06 19:31:12 UTC
*** Bug 370197 has been marked as a duplicate of this bug. ***
Comment 13 Matthias Schwarzott gentoo-dev 2011-06-07 18:22:41 UTC
would it help to add an use flag extras to udev-171, that internally enables all of the split flags? or at least gudev if that is what the other packages depend on.
Comment 14 William Hubbs gentoo-dev 2011-06-07 20:37:44 UTC
(In reply to comment #13)
> would it help to add an use flag extras to udev-171, that internally enables
> all of the split flags? or at least gudev if that is what the other packages
> depend on.

I don't think this is a good idea. I think the other packages should be fixed, and we should just wait for this to happen.  After all, this is ~arch, and there will be occasional issues like this.
Comment 15 Sebastian Pipping gentoo-dev 2011-06-07 21:50:31 UTC
If

  USE="extras"

has effectively become

  USE="acl action_modeswitch keymap hwdb gudev"

in udev why not keep flag extras as a temporary way of turning all of these other flags on until reverse dependencies have been updated?  That would relax the transition noticably, especially as you seem to expect other developers to fix the transition for you.  Thanks for consideration.
Comment 16 William Hubbs gentoo-dev 2011-06-08 03:35:07 UTC
(In reply to comment #15)
> That would relax
> the transition noticably, especially as you seem to expect other developers to
> fix the transition for you.  Thanks for consideration.

If developers want me to fix their packages that is one thing, but as you know, we are not supposed to touch packages we do not maintain without talking to the maintainer first.
Comment 17 Matt Turner gentoo-dev 2011-06-08 03:48:08 UTC
(In reply to comment #15)
>

More than 1/3 of the bugs have already been fixed, so I really don't see it as a huge problem. Rather, it's a small one-time cost.
Comment 18 Sebastian Pipping gentoo-dev 2011-06-08 03:53:01 UTC
(In reply to comment #16)
> If developers want me to fix their packages that is one thing, but as you know,
> we are not supposed to touch packages we do not maintain without talking to the
> maintainer first.

Fair point.  For workload reasons it makes sense to distribute the fixing.  However, if others need fix their packages for udev-caused changes _after_ that changes has been made it means that (1) the tree is left in an unstanble status for a window of time of unknown length and (2) fixing depends on many people with unknown other priorities at this moment which makes a soon fix very unlikely.

With that said I think it's clear that temporary re-addition of use flag extras is a way to avoid all of that trouble at considerably low cost at your end.

PS: Any ideas on what to do with the "sys-fs/udev extras" in /usr/portage/profiles/targets/desktop/package.use already?


(In reply to comment #17)
> More than 1/3 of the bugs have already been fixed, so I really don't see it as
> a huge problem. Rather, it's a small one-time cost.

2 votes and 13 CCs on bug #370283 look like an indicator for a bigger problem to me rather than a small one.  This is no excuse for not re-adding extras to me.
Comment 19 Matt Turner gentoo-dev 2011-06-08 04:32:48 UTC
Why have we changed the behavior at the same time as splitting the extras flag?

I was just trying to figure out why my stage builds were emerging glib, and then I realized it was because what had been

IUSE="extras"

has now been turned into

USE="+acl action_modeswitch +keymap +hwdb +gudev"

These shouldn't be default on, should they? If packages need their functionality, they'll depend on it and portage will emerge udev as appropriate.

Please turn these off by default in IUSE.
Comment 20 William Hubbs gentoo-dev 2011-06-08 04:58:56 UTC
I am willing to consider adding the extras use flag back for a short
time.

Also, I am willing to help getting the packages fixed, and That route
would be the better one if we can make it happen soon.
Comment 21 William Hubbs gentoo-dev 2011-06-08 05:12:03 UTC
(In reply to comment #19)
> Why have we changed the behavior at the same time as splitting the extras flag?
> 
> I was just trying to figure out why my stage builds were emerging glib, and
> then I realized it was because what had been
> 
> IUSE="extras"
> 
> has now been turned into
> 
> USE="+acl action_modeswitch +keymap +hwdb +gudev"
> 

The reason for the split was that we followed upstream. Originally they had all of these options controlled by one switch, --enable-extras, in their configure script, but they  split them in this release.

> These shouldn't be default on, should they? If packages need their
> functionality, they'll depend on it and portage will emerge udev as
> appropriate.

I don't think portage will automatically re-emerge udev if another package requires udev with a use flag that is off; it will just give you an error and require you to set the appropriate use flag.

> Please turn these off by default in IUSE.

The default IUSE settings follow what upstream had as the defaults in their configure script, but we could change that. You feel that all of them should be off?
Comment 22 Matt Turner gentoo-dev 2011-06-08 05:35:47 UTC
(In reply to comment #21)
> (In reply to comment #19)
> > Why have we changed the behavior at the same time as splitting the extras flag?
> > 
> > I was just trying to figure out why my stage builds were emerging glib, and
> > then I realized it was because what had been
> > 
> > IUSE="extras"
> > 
> > has now been turned into
> > 
> > USE="+acl action_modeswitch +keymap +hwdb +gudev"
> > 
> 
> The reason for the split was that we followed upstream. Originally they had all
> of these options controlled by one switch, --enable-extras, in their configure
> script, but they  split them in this release.

Hah, sorry for being unclear. I understand the purpose in the split (I filed the bug). I meant, why have these been switched on by default whereas the extras flag was off by default?

> > These shouldn't be default on, should they? If packages need their
> > functionality, they'll depend on it and portage will emerge udev as
> > appropriate.
> 
> I don't think portage will automatically re-emerge udev if another package
> requires udev with a use flag that is off; it will just give you an error and
> require you to set the appropriate use flag.

Yeah, I think you're right, but it will tell you to turn on the flag when necessary, so I think the point stands.

> > Please turn these off by default in IUSE.
> 
> The default IUSE settings follow what upstream had as the defaults in their
> configure script, but we could change that. You feel that all of them should be
> off?

The problem is the dependencies, given that none of this functionality in udev has existed by default previously.

acl? ( sys-apps/acl dev-libs/glib:2 )
gudev? ( dev-libs/glib:2 )
action_modeswitch? ( virtual/libusb:0 )
keymap? ( dev-util/gperf )
hwdb?
    (
        >=sys-apps/usbutils-0.82
        sys-apps/pciutils
    )

acl is a global flag which is on by default everywhere, so it's not a problem.

acl is masked on mips though, so the addition of the on-by-default gudev flag pulls in glib into a minimal system install (including stage1 builds). Same situation with the others, although I don't really know what functionality they provide--without knowing I'd have to say they should be off by default.
Comment 23 William Hubbs gentoo-dev 2011-06-08 06:10:29 UTC
(In reply to comment #22)
> The problem is the dependencies, given that none of this functionality in udev
> has existed by default previously.

Ah ok, thanks for the explanation. :-)

It looks like the affected flags were acl, gudev, hwdb and keymap, so I turned off these flags in IUSE. rule_generator appears to be ok; it is just tied to an --enable/--disable switch without a dependency.

Let me know if you disagree with this.
Comment 24 Rafal Kupiec 2011-06-08 06:40:13 UTC
!!! One or more updates have been skipped due to a dependency conflict:

sys-fs/udev:0

  (sys-fs/udev-171-r1::gentoo, ebuild scheduled for merge) conflicts with
    >=sys-fs/udev-146[extras] required by (net-wireless/bluez-4.94::gentoo, installed)


Now you should fix bluez
Comment 25 William Hubbs gentoo-dev 2011-06-08 06:53:22 UTC
(In reply to comment #24)
> Now you should fix bluez

The bug for that is bug #370393. I'll fix that after I get some sleep. :-)
Comment 26 William Hubbs gentoo-dev 2011-06-08 07:18:52 UTC
(In reply to comment #18)
> Fair point.  For workload reasons it makes sense to distribute the fixing. 
> However, if others need fix their packages for udev-caused changes _after_ that
> changes has been made it means that (1) the tree is left in an unstanble status
> for a window of time of unknown length and (2) fixing depends on many people
> with unknown other priorities at this moment which makes a soon fix very
> unlikely.

My understanding is that The only thing it really does is prevents people who are running ~arch udev from upgrading to the newer udev if they have a package that has udev[extras] in its dependencies installed on their system. It does not affect our stable users, and it doesn't break any ~arch systems, because they don't get the upgrade. So, I'm not sure what you mean when you say this leaves the tree in an unstable state.

> With that said I think it's clear that temporary re-addition of use flag extras
> is a way to avoid all of that trouble at considerably low cost at your end.

Yes, it is true that temporarily re-adding the extras use flag would allow people to update udev to udev-171-*, but but when I remove the use flag again, which I would do at some point in the future, the issue would return for that upgrade unless all of the packages are fixed.

The question would be, how long should we keep the extras use flag around?
I would say a week or two at most.

> PS: Any ideas on what to do with the "sys-fs/udev extras" in
> /usr/portage/profiles/targets/desktop/package.use already?

This would actually be a pretty easy fix, just add the needed use flags to that line.
Comment 27 Sebastian Pipping gentoo-dev 2011-06-08 15:14:17 UTC
(In reply to comment #26)
> My understanding is that The only thing it really does is prevents people who
> are running ~arch udev from upgrading to the newer udev if they have a package
> that has udev[extras] in its dependencies installed on their system. It does
> not affect our stable users, and it doesn't break any ~arch systems, because
> they don't get the upgrade. So, I'm not sure what you mean when you say this
> leaves the tree in an unstable state.

Agreed, "unstable" may be too strong of a word.  What it does is that the thousands of ~arch users we have all see that conflict on each upgrade.  It looks like something wrong, they will try finding out what's wrong and waste time on that each.  They are annoyed by that message on each update.  It could be worse, but it's definitely not optimal, like a hick-up maybe.


> Yes, it is true that temporarily re-adding the extras use flag would allow
> people to update udev to udev-171-*, but but when I remove the use flag again,
> which I would do at some point in the future, the issue would return for that
> upgrade unless all of the packages are fixed.
> 
> The question would be, how long should we keep the extras use flag around?
> I would say a week or two at most.

The point of re-adding flag extras is to keep it around *until no other package depends* on that flag anymore, not for a fixed time.  By now we even have a question

  6. What steps are needed to remove a use flag from IUSE in an ebuild?

in our ebuild quiz to make sure new developers know about the safe way to do it.
Comment 28 Rafal Kupiec 2011-06-09 15:17:47 UTC
I dont know what have you done, but you messed things completely...
After sync i got this now:

emerge: there are no ebuilds built with USE flags to satisfy ">=sys-fs/udev-171[gudev]".
!!! One of the following packages is required to complete your request:
- sys-fs/udev-171-r1 (Change USE: +gudev)
(dependency required by "sys-fs/udisks-1.0.2-r4" [installed])
(dependency required by "@selected")
(dependency required by "@world" [argument])
Comment 29 Matt Turner gentoo-dev 2011-06-09 15:39:32 UTC
(In reply to comment #28)
> I dont know what have you done, but you messed things completely...
> After sync i got this now:
> 
> emerge: there are no ebuilds built with USE flags to satisfy
> ">=sys-fs/udev-171[gudev]".
> !!! One of the following packages is required to complete your request:
> - sys-fs/udev-171-r1 (Change USE: +gudev)
> (dependency required by "sys-fs/udisks-1.0.2-r4" [installed])
> (dependency required by "@selected")
> (dependency required by "@world" [argument])

It looks like _you_ don't know what you're doing.

Read the message. It's telling you that you need to enable udev's gudev USE flag for the udisks package.
Comment 30 Sebastian Pipping gentoo-dev 2011-06-09 15:50:31 UTC
(In reply to comment #28)
> I dont know what have you done, but you messed things completely...
> After sync i got this now:
> 
> emerge: there are no ebuilds built with USE flags to satisfy
> ">=sys-fs/udev-171[gudev]".
> !!! One of the following packages is required to complete your request:
> - sys-fs/udev-171-r1 (Change USE: +gudev)
> (dependency required by "sys-fs/udisks-1.0.2-r4" [installed])
> (dependency required by "@selected")
> (dependency required by "@world" [argument])

Until recently the profile only enabled use flag extras on sys-fs/udev.  As of now it also enables gudev, hwdb and keymap:

  # fgrep -R gudev .
  ./targets/desktop/package.use:sys-fs/udev extras gudev hwdb keymap
                                                   ^^^^^
So this should be fixed by now.


(In reply to comment #29)
> It looks like _you_ don't know what you're doing.

While I agree that "messed things completely" to be an exaggeration, your statement doesn't seem helpful to me.


> Read the message. It's telling you that you need to enable udev's gudev USE
> flag for the udisks package.

The point is that he probably should not have to do that for an app that's installed as widely: it should be handled by the profile.  So that's a valid point to me.
Comment 31 Matt Turner gentoo-dev 2011-07-31 00:06:31 UTC
All blocking bugs are now closed. Should we close this?
Comment 32 Sebastian Pipping gentoo-dev 2011-07-31 00:21:31 UTC
(In reply to comment #31)
> All blocking bugs are now closed. Should we close this?

In that case the flag "extras" can and should now be resolved, in my eyes.  I propose renaming the bug to communicate that goal visibly.
Comment 33 William Hubbs gentoo-dev 2011-07-31 01:06:17 UTC
Since all of the blocking bugs are closed, this is now resolved.
Comment 34 Sebastian Pipping gentoo-dev 2011-07-31 01:08:58 UTC
(In reply to comment #33)
> Since all of the blocking bugs are closed, this is now resolved.

It would be great if you could start addressing my comments, too.  Comment #32 to be precise.  Thanks.