Re: using perl in preinst script
* Steve Langasek [2010-12-28 15:46 -0800]:
> On Tue, Dec 28, 2010 at 11:48:18PM +0100, Carsten Hey wrote:
> > * pam_getenv and pam-auth-update from libpam-runtime:
> > pam_getenv is 76 lines of code. pam-auth-update is 490 lines of
> > code and has been added after Lenny has been released.
> And the lack of pam-auth-update has been a glaring gap in Debian
> functionality for the better part of a decade before that. I'm not
> dropping pam-auth-update from the package, and I'm not rewriting it in
> C or in shell ...
I neither suggested dropping it nor that you should rewrite it and did
not question that it is useful. If existing perl scripts would be
rewritten, this would be something to be done by people wanting to make
perl non-essential in agreement with the according maintainers. Also
I did not say that perl-base should be made non-essential, I did list
what is missing from being able to do so.
> > > I cannot imagine this ever happening at a practical level.
> > Not if people continue to add new perl scripts to essential and to write
> > new preinst scripts in perl.
> Which there is zero reason for anyone to go out of their way to avoid doing.
One reason would be to avoid a possible later rewrite (in python and
done by you in your case) if it would be decided that perl-base should
be made non-essential in future.
This was not meant as attack or to let libpam-runtime appear as bad
example (which it is not), I wanted to point that if there are plans to
make perl-base non-essential, then we should all avoid doing things that
would make fulfilling this plan more difficult and if there is no such
plan, than there is no point in avoiding writing preinst or postrm
scripts in perl or avoiding to use perl in essential packages. Due to
the missing consensus there is currently no right or wrong and the most
sane thing is to assume that everything stays as it is now.
This missing consensus leads to more workload, either for people
avoiding perl in maintainer scripts and essential packages because they
wrongly assume that perl-base might become non-essential, or because of
writing perl scripts that are going to be replaced by implementations in
> I don't see any way that it would benefit Debian to drop perl from the base
> system and limit ourselves to C, C++, and shell as implementation languages.
There are advantages of having a small minimal Debian installation
(i.e., essential + apt), but there are more worthwhile things to do than
removing a language from essential to save 4 MB.