Oleg Verych wrote: > Bob Proulx 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. > 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? 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. 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 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. I have not looked at those scripts previously and did not spend time on them now so can't vote yes or no on their overall good or bad style and are just commenting on them statistically. > > If there is a problem with adduser then it should be reported so that > > it can be addressed. The BTS does not show anything too scary. It is > > in heavy use by thousands of users. I think that specific examples of > > problems need to be shown before we can start thinking that there is a > > problem with adduser. (Although I am sure that the code could be > > improved. That is almost always true of any project.) > > So, if exim4 expressly wants dynamic ID, i will be on my own. I am certainly not the one the convince. The documented proceedure is to coordinate with the base-passwd maintainer. But I would expect that you would need a pretty strong reason. Among other things none of the other MTA packages (e.g. postfix, sendmail) have one and so would need to say why exim4 is requiring a global id assignment when the others don't. > As for sources in perl, i just can't understand why it get so big for > some little benefit. > > our $configfile = undef; > our $found_group_opt = undef; > ... > my $existing_user = undef; > my $existing_group = undef; > ... That in partcular looks like a typical process so that 'perl -w' and 'use strict;' are happy and do not produce usage warnings. > 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? Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
