Release impact of introducing a new archive section?

Josh Triplett josh at joshtriplett.org
Thu Dec 8 17:01:47 UTC 2016


On Thu, Dec 08, 2016 at 05:55:37PM +0100, gregor herrmann wrote:
> On Thu, 08 Dec 2016 08:44:15 -0800, Josh Triplett wrote:
> > > While you are in there, there is #816693, also I'm unsure (and offline
> > > atm) how many perl6 packages we currently have.
> > As far as I can tell, we have 2 such packages: perl6 and perl6-panda.
> 
> See my other mail.

*nod*; I didn't know about the other packages.

> > We have several packages named libperl6-*, but reading their
> > descriptions, they actually provide modules for perl5 that emulate perl6
> > functionality, so the package names seem incorrect.
> 
> No. perl5 modules named FOO::BAR are packages as libFOO-BAR-perl, and
> in this case we have perl5 modules named Perl6::Something, so this
> naming just follows the Debian Perl Policy, even if it looks a bit
> strange.
> 
> Perl6 packages are/will be named perl6-*.

Ah, I see; that makes sense.  So, perl6 X::Y::Z modules will use the
naming perl6-x-y-z?

> > Python 2 and 3 packages both use the "python" section, and distinguish
> > packages by package name (python-* versus python3-*); might it make
> > sense to just use the "perl" section, and distinguish modules for perl5
> > versus perl6 by package name?
> 
> I don't think so. perl5 and perl6 are "sister languages" but you
> can't run perl5 code under perl6 or vice versa (ignoring some fancy
> hacks) and you can't build a perl5 and perl6 variant from the same
> source etc.
> 
> In my understanding, python3 is, despite some incompatibilities, the
> successor / next version of python(2); perl 6 is a new language from
> the same family, but not the next version/successor of perl5.

The level of difference aside, Python 2 and Python 3 have the same issue
in terms of incompatibilities, and it takes a great deal of care (and in
some cases some "fancy hacks" such as six or 2to3) to write or translate
code to work with both.  Many modules just work with one or the other.

In any case, I don't have any objections to a new section; I just wanted
to check about the alternative possibility of using "perl" (which in any
case seems better than using "interpreters").



More information about the Pkg-rakudo-devel mailing list