Re: Feaping Creature-ism in core Debian Packages
>>>>> "AC/DS" == Dale Scheetz <dwarf@polaris.net> writes:
AC/DS> On Thu, 2 Sep 1999, Craig Sanders wrote:
>> On Wed, Sep 01, 1999 at 07:44:45AM -0400, Dale Scheetz wrote: >
>> Personally I object to perl routines embedded in a rules file,
>> but the > point I was trying to make is that placing perl-base
>> in the essential > packages creates a "camel's nose"
>> situation. Those who use perl are > now allowed to do so in
>> installation scripts as well as in package > build
>> circumstances.
>>
>> there is nothing wrong when this happens, as long as only those
>> 'perlisms' available in perl-base are used.
AC/DS> But that _is_ my point. Just because perl-base is
AC/DS> essential, and always going to be on the machine, doesn't
AC/DS> speak to the other "versions" of perl that may be on the
AC/DS> system at build time, and doesn't speak to which perl
AC/DS> libraries may be available and used by mistake.
AC/DS> Alan Cox made
AC/DS> some very crisp statements about perl
AC/DS> The following comments are his, and suggest that LSB will
AC/DS> _not_ specify perl for use in installation scripts:
>> From alan@lxorguk.ukuu.org.uk Thu Sep 2 07:32:05 1999
AC/DS> It sucks but its reality. Majordomo broke on 3 out of 4
AC/DS> "minor" revision updates to perl I did. The perl community
AC/DS> informs me that there is no perl grammar. They don't
AC/DS> themselves know what is and isnt perl except by feeding it
AC/DS> through interpreter of the week.
Majordomo broke on the introduction of Perl5 as opposed to Perl4
that isn't a minor revision.
Much of perl _is_ standard. Many programs run the same between
version revision. It is well known that exploiting intricate
non-standard usages can change on a regular basis.
AC/DS> So perl is like this We have to standardise on a specific
AC/DS> minor revision If we standardise on it and bugs (eg
AC/DS> security stuff) is found the perl community don't back fix
AC/DS> old perl. You move on your scripts break.
sometimes scripts break. I still have scripts that I wrote when
perl.4.017 was current. They still work well
How about using just core level perl, and provide your own
modules for things that are critical to you.
Perl like C requires that one think seriously about portiblity
when writting code
AC/DS> Thats going to be a _big_ dependancy problem.
AC/DS> Alan
Unless you want to use the multi-byte UTF code, much of perl
is pretty standard. You might as well use current versions of perl.5.3
and make sure that the scripts work with perl.5.2.
and -don't- use xsub code, it generally isn't portable.
you might want to use the perl Makefile.PL to identify
the actual local environment, instead of just using
hardcoded scripts.
--
=================================================
Kermit Tensmeyer - kermit@brite.net [ dallas, texas ]
and this is my opinion, and not the property of anyone else!
Reply to: