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

Re: New 5.6 Perl



On Mon, Oct 09, 2000 at 06:17:33PM -0700, Darren/Torin/Who Ever... wrote:
>   * Adapt Brendan's libperl changes.
>     Be sure and link suidperl static.

I figured that this was not critical, since suidperl runs briefly before
exec-ing [the static] /usr/bin/perl.  YMMV.

>I've not put in a separate libperl5.6-dev package since you'd need the
>full Perl package to do that anyway.  Possibly, perl-5.6 should provide
>libperl5.6-dev?

Probably a good idea.  I created libperl-dev for the static library and
the .so link as neither of which are required for anything other than
building embedded applications.  The headers (which I also included) are
required for building modules as well as embedded apps (duh!), and a
separate package to save 1Mb or so is probably overkill in hindsight.

>The tasks to have done by Saturday are:
>  * Remove the alternatives - there should be One True Perl
>    This means that I have to build the 5.004 and 5.005 packages and
>    remove the alternatives from there too.  This is why this isn't done
>    for this release.

So as I understand it, this perl-5.6 package will have a /usr/bin/perl
binary (and perl5.6.0 presumably), whereas perl-5.005 for example will
only have perl5.005).

This is certainly a good thing, and will greatly simplify the mess of
pod2* etc. alternatives as well...

I would however *still* argue in favour of a single perl package, and
the need to provide at least limited binary compatibility if possible to
avoid trashing binary modules en masse when a new version is installed.

Note that doing so does not preclude the possibility of additional
perl-5.005 or perl-thread packages if the need does actually arise, or
perl6 packages for that matter if such a beast ever emerges from the
mire of RFCs.  None of these would provide either perl or perl5.

This latter [perl6] case I would see as being a far bigger issue than
that of revisions within 5.x.

If there are major backward compatibility issues with perl6, I would
propose the packages:

    perl (provides perl5)  perl6
    perl5                  perl (provides perl6)

with the change from the first situation to the second when the majority
of dependent packages have been ported.

My own experience with 4.036 -> 5.000 was fairly positive, and I'm
hoping that 5.x -> 6 will be similar.

Regards,
-- 
Brendan O'Dea                                        bod@compusol.com.au
Compusol Pty. Limited                  (NSW, Australia)  +61 2 9810 3633



Reply to: