On Sun, 2004-02-08 at 06:10, Steven Elling wrote: > On Fri, 2004-02-06 at 02:32, Paul de Vrieze wrote: > > On Friday 06 February 2004 09:14, Stewart Honsberger wrote: > > > Paul de Vrieze wrote: > > > > Basically muttrc is not of the same class as passwd, fstab and group. If > > > > you're up to it, just move the three to somewhere else and reboot. After > > > > that I think you can appreciate that one must not be enabled to > > > > overwrite them. > > > > > > Some people run Linux because they don't like their operating system > > > protecting their toes from their own firearms. > > > > Maybe my wording was a bit too harsh. But I cannot see the point of offering > > the user the option of replacing his passwd/fstab/group with one that with > > 99% certainty is wrong > > > > Paul > > More importantly; which has been brought to the attention of the devs > and ignored; is that useradd, userdel, usermod, groupadd, groupdel, > groupmod or similar should be used the modify /etc/password and > /etc/group. >
Which ever way you look at this, its a tacky issue. Some people do not want an ebuild to auto change these, so do. You cannot really leave ._cfg* around, as your newer users have the hang of messing the merge (exactly the reason why baselayout do not let passwd and shadow leave ._cfg*'s around) My personal opinion to this is that if something need a new user/group, then baselayout should get it added for new installs (but not leave a ._cfg* around - thus existing do not get updated), but the ebuild should add it via enewuser and enewgroup (eutils.eclass), as it will then only be done for those needing it, and the risk is much lower. For those not wanting portage to tweak, we might introduce a USE flag, but until we can get portage to display _all_ messages post bulk merge, it is not really feasible, as the message to add the user gets lost in the noise. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa
signature.asc
Description: This is a digitally signed message part
