Subject: Packages using perl in inst scripts and not requiring perl: normal?

From: Yves Arrouye <[email-masked]>
Date: Wed, 24 Jul 1996 00:22:42 +0200

Hello,

Is it normal that some packages do use perl in their installation scripts
and do not have a Requires: perl field though perl is not a required
package?

Yves.

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Wed, 24 Jul 1996 12:50:32 +0200 (MET DST)

> and do not have a Requires: perl field though perl is not a required

Good point. Perl is part of the base system though; I think either
perl should be Essential or the packages should depend on perl. I'd
prefer the former.

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Guy Maor <[email-masked]>
Date: Wed, 24 Jul 1996 10:24:19 -0500 (CDT)

> and do not have a Requires: perl field though perl is not a required

The base package installs a perl binary.  When you install a perl
package, the binary gets replaced.  I suppose that removing the perl
package after installing it would be problematic.

Guy

---

From: Dan Stromberg <[email-masked]>
Date: Wed, 24 Jul 1996 15:32:50 -0700

I'd prefer the latter.  In fact, I'd prefer it if packages didn't
require perl just to get installed.

Perl is an abomination in the eyes of most language designers.

Python, the ML variants, the lisp variants - these are clean languages
with small cores and large libraries, all having interpreted
implementations (and sometimes compiled as well).  Perl, the
paradigmatic large-core, kitchen sink language, ain't.

---

From: Bill Bumgarner <[email-masked]>
Date: Thu, 25 Jul 96 00:36:51 -0500

I see a language war on the horizon...

Anyway-- I wholeheartedly second Dan's thoughts in regards to language usage within the installation.  We would be much better off to remove all dependencies on perl from anywhere in the installation process.  Perl is the best language in the world for hacking, but one of the worst for serious programming, writing production code, or generating any kind of body of work that anyone other than the author has any hope of maintaining.  Perl provides a kitchen sink environment with a syntax reminiscent of line noise that relies heavily on voodoo and side-effects.  As a production language, it is wholly unacceptable.

As well, I have experienced numerous cases where Perl's behaviour changed slightly between 'minor' revisions.  Other disturbing behaviour includes inconsistent behaviour across platforms or even across similar platforms, but different hardware.   Random and completely unexplained crashes of the perl pre-processor have also plagued all of the large perl-based projects I have ever made the mistake of contributing to.

Frankly, the thought of using Perl on *anything* that could be considered "production quality" or "mission critical" is just plain scary.

Python is an awesome language-- once one gets by the indention based scoping, it is a joy to use and program in.  It has a highly consistent and easy to use object oriented paradigm that is used throughout every aspect of the language.  It is very easy to produce production quality code in python that is easily read and maintained by others-- not so with perl.  Python is also one of the most portable languages available;  almost every bit of system-dependent code is hidden behind an abstract object-based API that makes allows the programmer to pretty much ignore the type of the target platform.  Yet, it is well-written such that there is little power sacrificed to achieve this level of portability.

ML and Lisp are both wonderful languages-- but are somewhat esoteric in nature... Tcl is an excellent embedded, short script language-- but is almost to high of a level language to be truly useful for configuration of an OS.

Guile may someday be the language of choice, but it has a long ways to go.  Java is great if you want to animate part of your web page, but it is far from being a production quality language (as well, the current licensing 'aggreement' foisted on the world by Sun makes it, in effect, a completely non-free language).

At this moment, probably the best thing that could happen would be for Debian to include an *extremely* trimmed down Python environment as the standard scripting environment that all packages can use to do any pre or post installation manipulations.  Realistically, this ain't going to happen-- there are way to many people who have their heads so full of perl that they can't think any other way.  Oh well... It would be nice if we could, at least, have a trimmed down perl environment in the base.

Anyone here read +Code Complete+ -- a rather awesome collection of knowledge in regards to creating quality software packages?  Go ahead and TRY to fit perl into a REAL development environment...  I have done it-- it hurts.

b.bum

---

From: "James A. Robinson" <[email-masked]>
Date: Thu, 25 Jul 1996 02:33:25 -0400

> Yves Arrouye:

Well, I don't think so.  The last I knew, perl is a on the base
system, installed in /bin/perl.  It is then moved to /usr/bin/perl
with a symlink back to /bin/perl when perl proper is installed.  This
is all from hazy memory, but the point is that we are supposed to
safely rely on perl being on the system.  I think there was a problem
with the link disappearing, or else there was a policy change and lots
of us missed it.

> Dan Stromberg

Erm. perl is also extremely popular and flexible.  I don't want to get
into a language war; I do want to point out that many sysadmins know
perl, and use it a lot.  It is therefore a natural choice for many
when programming something to do system setup.  I'm certainly not
going to give up something that lets me quickly get my job done just
because it isn't as "well designed" as some other language.

Jim

---

From: Maarten Boekhold <[email-masked]>
Date: Thu, 25 Jul 1996 10:50:18 +0200 (MET DST)

> paradigmatic large-core, kitchen sink language, ain't.

But it's extremely usefull......

Maarten 

_____________________________________________________________________________
|     Maarten Boekhold, Faculty of Electrical Engineering TU Delft,   NL    |
|      [email-masked]   [email-masked]     |
|		          Rave or Die!!!!!!                                 |
-----------------------------------------------------------------------------

---

From: Yves Arrouye <[email-masked]>
Date: Wed, 24 Jul 1996 23:14:05 +0200

Erick Branderhorst writes:
 > Yes, because perl is a base package and can be assumed installed on Debian
 > systems.

No, because perl is not essential and can be removed at anytime.
Yves.

---

From: Yves Arrouye <[email-masked]>
Date: Wed, 24 Jul 1996 23:24:36 +0200

> perl should be Essential or the packages should depend on perl. I'd

Hmmm. On my system there are 23 packages needing perl (and 726 packages
installed). Some of them could use sh, of course ;-) Seriously, I think
perl should not be required but that packages that use it for their
installation script require it as they should. It's cleaner, IMHO, not
to force someone to have a package that may be unnecessary given his
installation.

But then here's something that could make perl stick to the system:
dpkg-divert, update-rc.d and friends are written in perl and parts of
dpkg, which is required.
Making dpkg depend on perl (as it should) will make perl unremovable
(well, at least not without warnings). I prefer to have dpkg depends
on perl so that if its tools are rewritten in C perl would not
necessarily stick unneeded on some installations.

Yves.

---

From: Michael Shields <[email-masked]>
Date: Thu, 25 Jul 1996 15:09:37 +0000

>Perl is an abomination in the eyes of most language designers.

These people must not be sysadmins.  :-)

--
Shields, CrossLink.

---

From: "Brian C. White" <[email-masked]>
Date: Thu, 25 Jul 1996 16:37:43 -0400

>Perl is an abomination in the eyes of most language designers.

Perl wasn't so much designed as it was evolved.

It's full of handy side-effects which can make it difficult at times and
immensly useful at others.  You can write upgly code in Perl, but how
is that any different from C?

Like C, Perl is one of the most popular girls in school...  And it's not
because she's the prettiest.

                                        Brian
                               ( [email-masked] )

-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.

---

From: [email-masked] (Kai Henningsen)
Date: 26 Jul 1996 09:40:00 +0200

> because she's the prettiest.

Definitely. There are even some things in Perl that I haven't yet found a  
non-ugly way to do.

It's useful. But it's also awfully ugly.

MfG Kai

---

From: Juergen Menden <[email-masked]>
Date: Fri, 26 Jul 1996 12:06:33 +0200 (MET DST)

> No, because perl is not essential and can be removed at anytime.

well, perl even isn't in .../binary-*/base. AFAIK it's therefore not
even a base package. :-)

jjm

-- 
Juergen Menden                   | Disclaimer: The opinions expressed by me, 
tel:    +49 (89) 289 - 22387     +-----------+ are (usually) not the opinions 
e-mail: [email-masked]     | of anyone else on this planet.

Hi! I'm a .signature virus!  Add me to your .signature and join in the fun!

---

From: "James A. Robinson" <[email-masked]>
Date: Fri, 26 Jul 1996 06:46:08 -0400

> well, perl even isn't in .../binary-*/base. AFAIK it's therefore not

Perl is installed with the base disks, base1-base3, or base1.1.tar.gz,
when you first install the system.  From there, the devel/perl
package, which includes all the lib files and man pages and stuff, is
supposed to manipulate /bin/perl properly.

Jim

---

From: Dan Stromberg <[email-masked]>
Date: Fri, 26 Jul 1996 09:28:56 -0700

> is that any different from C?

True, C can get pretty bad - but then, at the time C was popularized, it
really -was- one of the best things around - at least for some varieties
of systems programming.

I don't believe we can say even that much of perl.

> because she's the prettiest.

...and sadly, it isn't because she has a great personality, either.  

Perl doesn't have a whole lot going for it, beyond mass acceptance.

Coming back to the original issue: how many install scripts need to be
more sophisticated than what is amendable to expression in POSIX shell
syntax, plus "make"?  How many even should?

And really, how many linux systems don't have a /bin/sh that understands
POSIX shell syntax?  I used to use ash as my /bin/sh, but switched back
to bash before long.

---

From: [email-masked] (Kai Henningsen)
Date: 27 Jul 1996 09:37:00 +0200

> syntax, plus "make"?  How many even should?

As for install scripts, I don't know. In general, however, there are two  
very important things that are better in perl than in sh+utilities:

1. Quoting *is* actually a lot cleaner. This is one of the things perl got  
   right. Sometimes, that's important; I remember when I just couldn't
   make a shell script work for all cases when _some_ of these cases had
   single quotes in the raw data - I just couldn't get the quoting right.

2. Performance is often better, because you need to start a lot less
   processes. I've seen incredible speedups in some cases.

Of course, both of these are only important in very specific cases. So the  
rule should probably be (especially in view of the voluntary nature of the  
developers):

If you think you can hack it with the shell, please do.

Otherwise, use whatever is necessary.

MfG Kai

---

From: Dan Stromberg <[email-masked]>
Date: Tue, 30 Jul 1996 10:53:53 -0700

For absolute clarity...

I in no way wish to assert that perl is categorically inferior to the
bourne family of shells, for scripting.

I do, however, wish to assert that:

1) perl is an incremental improvement over /bin/sh, one that threatens
to sidetrack many programmers from moving -farther- ahead to systems
much nicer than perl.

2) Install scripts virtually never benefit from anything beyond what can
be handled smoothly thru /bin/sh and supporting programs.

IMO, interactive install scripts shouldn't be interactive - or should at
least provide an option to override repeated questions, across N
installs of a package or system.

---

From: Ian Jackson <[email-masked]>
Date: Thu, 1 Aug 96 02:09 BST

> and do not have a Requires: perl field though perl is not a required

This is OK, so long as they only use the bits of Perl that are on the
base disks.

Ian.