Re: input into perl 6 packaging required
On Sun, May 06, 2018 at 02:31:49AM +0200, gregor herrmann wrote:
> On Sat, 05 May 2018 21:16:08 +0200, Robert Lemmen wrote:
>
> > we are currently thinking about different ways to package perl 6
> > modules, and would love to get your ideas an input! the basic problem is
> > that perl 6 pre-compiled modules on load, and we have two ways to deal
> > with this: ship the precompiled modules, making each package depend on a
> > fairly specific runtime version, or pre-compile on module install and
> > runtime upgrade. Details at https://wiki.debian.org/Perl6PreCompProposal
> I'm afraid I can't really help here ... My gut feeling says that
> something like the python solution might be ok for perl6 as well.
Yeah, I'd go for the 'compile on installation time' approach too
if that's possible. Tight dependencies and frequent transitions seem
quite a burden to me.
I believe the emacs packaging world also does something like this.
Implementation-wise, using deb-triggers(5) is probably the way to go
(just in case you aren't already aware of those.)
> > - are the tight relationships between the packages and the runtime and
> > the resulting need for transitions a problem?
>
> Not really. We have 4 package which need the exact perl dependency,
> the rest is fine with 5.2x, so needs a transition only (once a year)
> per a next major release.
This is also further helped by the fact that even minor Perl 5 upstream
releases are quite infrequent.
> > - how does this scale? would it still work if all modules were involved,
> > not just the -xs- ones?
>
> That might be difficult. The annual transition, which involves 500-600
> packages needs quite some preparation (due to backwards-incompatibale
> changes) and takes a few days. If this involved a few thousand
> packages it might take quite some time.
Indeed. This is already a major yearly effort in the current scheme.
Just getting the 600 packages in buildable shape for a simultaneous
mass rebuild is often quite a bit of work due to unrelated changes in
the archive during the development cycle. I shudder to think of the
coordination that would be required for 3000 packages.
Hopefully the project wide trend for CI improvements will ease this in
the long run.
--
Niko
Reply to: