Re: adduser kills sound pt. 3
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
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
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.
> olecom@flower:$ du -hs adduser deluser ../share/perl5/Debian/AdduserCommon.pm
> 32K adduser
> 16K deluser
> 8.0K ../share/perl5/Debian/AdduserCommon.pm
> 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.
Found 745 LOC
Found 142 comment lines
Found 348 LOC
Found 63 comment lines
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?
- From: Oleg Verych <email@example.com>