[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: