Summary: | sys-fs/{udev,eudev}: superfluous hard gperf dependency | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system, eudev |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
SpanKY
2013-01-18 04:53:27 UTC
It seems to work like that except it's very easy to miss it when version bumping since it will just return 0 and then generate empty(?) file. We might need check like done for secure_getenv: if ! [[ $(grep -i gperf Makefile.am | wc -l) -eq 24 ]]; then eerror "The line count of gperf failed, see bug #452760" die fi :-/ fixed in tree for -r4 and 9999 * The line count for secure_getenv() failed, see bug #443030 * ERROR: sys-fs/udev-9999 failed (prepare phase): * (no error message) # LC_ALL=C date --utc Mon Jan 21 17:37:09 UTC 2013 Just synced Noticed this is not fixed in sys-fs/eudev, reassigning I mean Comment #0 (In reply to comment #4) > Noticed this is not fixed in sys-fs/eudev, reassigning Fixed in eudev. Thanks for the report! Upstream (git, after release of udev-205) made the dev-util/gperf dependency even harder to avoid: http://cgit.freedesktop.org/systemd/systemd/commit/?id=9d7d42bc406a2ac04639674281ce3ff6beeda790 I just made dev-util/gperf a hard DEPEND on sys-fs/udev-9999 again. I don't see gperf being a problematic dependency -- but there might be something I don't know. vapier? i was trying to avoid stupid stuff on embedded setups. if it's not really feasible with the current code like it was before, then i guess there's not much to be done. ideally they'd include generated files like this in their tarballs, but i'm guessing their releng process sucks and can't cope. (In reply to SpanKY from comment #8) > i was trying to avoid stupid stuff on embedded setups. if it's not really > feasible with the current code like it was before, then i guess there's not > much to be done. ideally they'd include generated files like this in their > tarballs, but i'm guessing their releng process sucks and can't cope. in eudev we only depend gperf for USE=keymap and we only test in configure.ac for gperf if --enable-keymap. I just grepped that source tree and I can't see any other reason for it. Comments on whether I'm missing anything? (In reply to Anthony Basile from comment #9) > (In reply to SpanKY from comment #8) > > i was trying to avoid stupid stuff on embedded setups. if it's not really > > feasible with the current code like it was before, then i guess there's not > > much to be done. ideally they'd include generated files like this in their > > tarballs, but i'm guessing their releng process sucks and can't cope. > > in eudev we only depend gperf for USE=keymap and we only test in > configure.ac for gperf if --enable-keymap. I just grepped that source tree > and I can't see any other reason for it. > > Comments on whether I'm missing anything? that's specific to eudev. upstream udev (systemd) doesn't have the hwdb support optional, or the keymap (keyboard) hwdb rules separated from the overall hwdb support. it's always installed on every configuration you can throw the build-sys at. and as per upstream systemd ML from upstream's mouth, the hwdb data may or may not be used for essential functionality, and it may or may not cause undefined behavior when it's missing. so i don't think restoring the flag to retain it's optionality is either safe, sane or worth the effort of carrying custom #ifdef -patch forever. imho :) (In reply to Samuli Suominen from comment #10) > (In reply to Anthony Basile from comment #9) > > (In reply to SpanKY from comment #8) > > > i was trying to avoid stupid stuff on embedded setups. if it's not really > > > feasible with the current code like it was before, then i guess there's not > > > much to be done. ideally they'd include generated files like this in their > > > tarballs, but i'm guessing their releng process sucks and can't cope. > > > > in eudev we only depend gperf for USE=keymap and we only test in > > configure.ac for gperf if --enable-keymap. I just grepped that source tree > > and I can't see any other reason for it. > > > > Comments on whether I'm missing anything? > > that's specific to eudev. > > upstream udev (systemd) doesn't have the hwdb support optional, or the > keymap (keyboard) hwdb rules separated from the overall hwdb support. it's > always installed on every configuration you can throw the build-sys at. > and as per upstream systemd ML from upstream's mouth, the hwdb data may or > may not be used for essential functionality, and it may or may not cause > undefined behavior when it's missing. > so i don't think restoring the flag to retain it's optionality is either > safe, sane or worth the effort of carrying custom #ifdef -patch forever. > imho :) do we have any known instance of badness here when hwdb is missing? |