Summary: | gnome-base/gnome-settings-daemon: wrong udev rule location | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | poncho <poncho> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, poncho, udev-bugs |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 433916, 507092 |
Description
poncho
2014-05-03 17:11:14 UTC
I have seen all distros are happy with it living in /usr... @udev, can you explain me the reasoning for installing it in / and what is the proper way to do so? (to report to upstream and be able to explain them the reasoning, otherwise I guess they won't want to make the build system more complicated without a clear gain) Thanks (In reply to Pacho Ramos from comment #1) > I have seen all distros are happy with it living in /usr... @udev, can you > explain me the reasoning for installing it in / and what is the proper way > to do so? (to report to upstream and be able to explain them the reasoning, > otherwise I guess they won't want to make the build system more complicated > without a clear gain) > > Thanks use udev.eclass and $(get_udevdir), see bug 433916, and comments in the eclass, and just something like: cd /usr/portage grep get_udevdir */*/*.ebuild and you'll find examples to go around this is about respecting udevdir= variable in udev.pc (and of course udev must be installed to / because it's required in early boot and not everyone uses initramfs) so something like... inherit udev and in src_install(): emake DESTDIR="${D}" udevrulesdir="$(get_udevdir)"/rules.d install i'm sure you can figure rest :) +*gnome-settings-daemon-3.12.2 (31 May 2014) + + 31 May 2014; Pacho Ramos <pacho@gentoo.org> + +gnome-settings-daemon-3.12.2.ebuild: + Version bump, fix udev rule installation (#509484 by poncho and ssuominen) + This seems to be a problem again. Tested 3.20.1 and ~3.22.1. (In reply to Matt Turner from comment #5) > This seems to be a problem again. Tested 3.20.1 and ~3.22.1. Yes, due to EAPI bump. I've already filed bug 606826 yeah, it's better explain in the other bug report (is due to a different issue than this original one) |