* Bob Proulx > > Oleg Verych wrote: >> I'm just a user, but developers seem to have some problems in the >> past: #208848. > > But Bug#208848 says that cron needed a dependency upon adduser, which > it now has because of that bug. Reading that bug this was > specifically for build daemons with a minimum system without adduser > otherwise installed. I don't see anything about adduser misbehaving. > That bug in particular was filed against cron not adduser.
* Bob Proulx > >> As i said, i will try to do a simple solution. If i will fail, so be it. > > The original poster Rick Spillane seemed to be having trouble with > /etc/group becoming corrupted. Are you having similar problems? > > What are you trying to do? > Getting rid of adduser. Misbehaving is one thing, bloated perl code is another (see below). >> One thing i can't see so far, why exim4 allocates dynamic UID. E.g. in >> situation, when i will have same "/etc/", "/var/spool/exim4" but >> different (re)installation sequence, UID may change, adding unneeded >> troubles. > > What trouble does it cause you when an installation on different > systems in a different order or on the same system after purging and > reinstalling system packages in a different order uses different > system ids? Ids may change and i will end up with /var/spool/exim4 owned by different user in case /etc/passwd is new. > There are a few globally reserved ids. But all of those must be > between 2 and 99 because traditionally other ids started at uid 100. > Additionally room must be left for the local admin to create system > ids. All globally allocated ids for all of Debian must fit between > 2-99 and are coordinated through the base-passwd maintainer. If i have /etc/passwd set up, i don't want to install adduser. If there will be setup option or prompt: "Do you want to add Debian-exim4 (with random UID)?" I want to say no. I don't want global ID. I want not random one. > Most systems, not just Debian, use dynamically assigned ids at package > installation time. This is a very common practice. It is sometimes > inconvenient but rarely causes serious enough problems to cause a move > to globally allocated ids. > >> [EMAIL PROTECTED]:$ du -hs adduser deluser >> ../share/perl5/Debian/AdduserCommon.pm >> 32K adduser >> 16K deluser >> 8.0K ../share/perl5/Debian/AdduserCommon.pm >> [EMAIL PROTECTED]:$ >> >> 56K just for random UID/GID or similar functionality is too much (IMHO, >> of course). Also it pulls "passwd" anyway. > > Hmm... We have completely different ideas of scale. That seems > pretty small to me. I ran perl-source-stats (from perl monks) on > those perl scripts and this is what it turned up. > > /usr/sbin/adduser > Found 745 LOC > Found 142 comment lines > > /usr/sbin/deluser > Found 348 LOC > Found 63 comment lines > > /usr/share/perl5/Debian/AdduserCommon.pm > Found 166 LOC > Found 31 comment lines I have not yet published aggressive cleaner of disk space, and it reports 48K of pure perl, i.e. no comments and redundant whitespace. And i care about every additional 4097 bytes, actually (for various reasons). > That is only 1053 lines of perl code in total across all three of > those files. I consider that quite reasonable. I am against the > practice of "perl golf" where the smallest number of strokes wins. > I much prefer verbose over terse if it improves readability. > For such functionality it's too much. So we just disagree :) ____ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]