Packaging Perl

Packaging Perl

[Achim Gratz]

I'm in the process of getting the next maintenance update for Perl-5.30
ready.  I'm trying to prepare for the inevitable major update (that will
not be binary compatible, so requires a complete repackaging of all
dependencies again) some time later.  I was planning to use the newly
available PROVIDES in cygport to have the perl_base package provide
"perl530" as a synthetic package name.  Then I'll arrange to generate
all Perl distributions with a REQUIRES for "perl530".  Eventually we'll
need to come up with a way of generating that info automatically, but I
don't think there's any place yet in the installation where the PROVIDES
information gets installed, so cygport can not pick up on it currently.
What I'm unsure about is what happens when we actually upgrade Perl,
which means the new Perl will providse something like "perl532" and we
have a bunch of distributions that require the new "perl532" plus a
bunch of not-yet-updated packages that require "perl530" instead.  The
idea is that either the packages needing the old Perl need to get
de-installed or the upgrade has to be held off until every package has
got an upgrade to the newer Perl.  On GNU/Linux zypper would offer at
least two solutions to chose from in this case, but setup just picks one
of the solutions that libzypp offers and that may not be the one the
user favored.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Packaging Perl

[Jon Turney]

On 03/06/2020 11:23, Achim Gratz wrote:
> 
> I'm in the process of getting the next maintenance update for Perl-5.30
> ready.  I'm trying to prepare for the inevitable major update (that will
> not be binary compatible, so requires a complete repackaging of all
> dependencies again) some time later.  I was planning to use the newly
> available PROVIDES in cygport to have the perl_base package provide
> "perl530" as a synthetic package name.  Then I'll arrange to generate
> all Perl distributions with a REQUIRES for "perl530".  Eventually we'll
> need to come up with a way of generating that info automatically, but I
> don't think there's any place yet in the installation where the PROVIDES
> information gets installed, so cygport can not pick up on it currently.

I think the perl cygclass in cygport can know the perl version being 
built against, and can add that to the requires?

I'm not sure doing it automatically for everything is possible.

> What I'm unsure about is what happens when we actually upgrade Perl,
> which means the new Perl will providse something like "perl532" and we
> have a bunch of distributions that require the new "perl532" plus a
> bunch of not-yet-updated packages that require "perl530" instead.  The
> idea is that either the packages needing the old Perl need to get
> de-installed or the upgrade has to be held off until every package has
> got an upgrade to the newer Perl.  On GNU/Linux zypper would offer at
> least two solutions to chose from in this case, but setup just picks one
> of the solutions that libzypp offers and that may not be the one the
> user favored.

Yes, setup needs a UI to present that choice.

Re: Packaging Perl

[Achim Gratz]

Jon Turney writes:
> I think the perl cygclass in cygport can know the perl version being
> built against, and can add that to the requires?

It knows the Perl version and can infer what the provide should be, yes.

But for the provides to be useful in a broader sense I think we need to
come up with a plan on how to record which provide(s) are present in the
current installation (given that the installation might be so old by the
time it gets upgraded that the current setup.ini doesn't have that bit
of information anymore).

> I'm not sure doing it automatically for everything is possible.

It sure is, the question is how to get it into the installation with the
least amount of changes.  To that end, I think we'd need to plop
something into the file system somewhere.  I believe the plan was that
provides do not create (empty) tar files or show up in the package
archive, but are purely metadata on the repository side, so that'd be
something that setup.exe would have to do.  It might be possible to
stuff it into installed.db, maybe even without changing the format
version, but I'm not sure that'd work for all scenarios.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables