Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 75478 - sys-apps/acl should warn people about the dangers of removing it
Summary: sys-apps/acl should warn people about the dangers of removing it
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Reported: 2004-12-23 13:12 UTC by ferret
Modified: 2004-12-26 00:49 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description ferret 2004-12-23 13:12:06 UTC
I have lost count of the number of people's systems I have had to help fix after
they removed 'acl' without re-emerging coreutils etc.  It's a silly thing to do,
but a common occurence nonetheless.  Currently a lot of people's existing
installations are having the acl USE flag "mysteriously" appearing on them, and
so they unset it and unmerge acl, to soon find out that 'ls' and such are
broken.  A warning at the end of the acl emerge would probably be helpful, along
the lines of:

ewarn "If you ever choose to set -acl in USE, remember to emerge --newuse world"
ewarn "*before* unmerging this package or sys-apps/attr, otherwise coreutils"
ewarn "(including the 'ls' command) may break"

Considering how easy it is to add a warning of this kind, I think it's worth it
if it saves even one system.  From my own experiences in #gentoo it would save
Comment 1 SpanKY gentoo-dev 2004-12-23 22:46:33 UTC
it wouldnt be useful at the end of the acl emerge ... they'd already shoot themselves in the foot ;)

we can force a check in pkg_setup ...
pkg_setup() {
    if built_with_use coreutils acl ; then
        eerror "Refusing to unmerge acl since coreutils was built with USE=acl"
        die "Dont shoot yourself, it hurts"
Comment 2 SpanKY gentoo-dev 2004-12-26 00:49:59 UTC
there doesnt seem to be a clean solution for this

when doing `emerge -C acl`, the ebuild would be read from /var/db/pkg/ rather than an updated version i put in the tree ... so users would still be screwed even if i added this check

there is no good way of figuring out if the user is upgrading and thus an older acl is being auto-cleaned, or if the user just did `emerge -C acl` ... both utilize the same functions and in the first case, we wouldnt want acl to bail