Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 316383 - plugdev group is only created in hal ebuild, but other software uses this group -> hal is getting deprecated
Summary: plugdev group is only created in hal ebuild, but other software uses this gro...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Daniel Gryniewicz (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 313389 315351
  Show dependency tree
 
Reported: 2010-04-20 17:04 UTC by H.Habighorst
Modified: 2011-04-10 11:30 UTC (History)
4 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 H.Habighorst 2010-04-20 17:04:39 UTC
Hi!

The issue is quite simple: With xserver-1.8, hal isn't necessary anymore and is considered deprecated. I did a fresh install on my laptop (2-3 days ago) and left out hal as it wasn't needed by any program. But I became error messages of dbus as the plugdev group was non-existant [due to hal being never installed, the group is created right at the beginning of the hal merge].

I think it would be wise to check in the dbus ebuild if the plugdev group is existant and to create it - or maybe better in udev.



Reproducible: Always
Comment 1 Daniel Gryniewicz (RETIRED) gentoo-dev 2010-04-22 19:27:46 UTC
Presumably, every ebuild that uses the plugdev group (for something other than allowing access to hal policy) needs to create it itself.  That's not a hal bug, that's a bug in other packages.
Comment 2 Gilles Dartiguelongue gentoo-dev 2010-09-29 15:40:13 UTC
I think it would be best to create the plugdev user in udev or udisk/upower and cie (best place imho is udev).
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2010-09-29 17:11:57 UTC
(In reply to comment #1)
> Presumably, every ebuild that uses the plugdev group (for something other than
> allowing access to hal policy) needs to create it itself.  That's not a hal
> bug, that's a bug in other packages.
> 

Exactly, for example:

/etc/udev/rules.d/70-libgphoto2.rules:ATTRS{idVendor}=="04fc", ATTRS{idProduct}=="504b", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary", GROUP="plugdev"

So we have:

libgphoto2-2.4.9.ebuild:	enewgroup plugdev


Ie. It should be in the packages making use of it.

I suggest to close this bug as NEEDINFO -> Point out the package using plugdev group, but not creating it.
Comment 4 Daniel Gryniewicz (RETIRED) gentoo-dev 2010-09-29 17:30:42 UTC
I don't believe there's a problem with multiple ebuilds creating it, so add it to udev, by all means.
Comment 5 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2010-09-29 19:03:47 UTC
I've hit this issue before in a new box I was purposely trying to avoid having to install hal.
Unless someone has any information about udev being planned to be deprecated, I'd suggest moving the creation of the plugdev group to udev and removing it from hal.
Comment 6 Gilles Dartiguelongue gentoo-dev 2010-09-29 19:16:37 UTC
hello @udev maintainers, would you please read this bug report and give us your opinion on moving plugdev creation to udev ebuild ? Otherwise, we would have to move it to each ebuild using it.
Comment 7 Samuli Suominen (RETIRED) gentoo-dev 2011-04-10 11:04:14 UTC
I don't agree with udev creating the plugdev group, it should be created by the applications that need it like most already does
The group is generally useless with modern systems using PolicyKit (including all the major desktops we have)

Should be closed as INVALID/NOTABUG -> Bug in the applications needing it, but missing enewgroup
Comment 8 Gilles Dartiguelongue gentoo-dev 2011-04-10 11:29:11 UTC
agreed, this is what  I ended up doing with gnome-bluetooth.