From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: perl update notification
Date: Thu, 01 Apr 2021 10:55:25 +0100 [thread overview]
Message-ID: <2E2ADAC5-B4FF-4B9B-A087-364C08DBA048@ipfire.org> (raw)
In-Reply-To: <0d924e08-858e-abb3-b56a-33405b981209@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]
Hello,
> On 1 Apr 2021, at 09:31, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>
> Hi All,
>
> After a lot of work I have successfully built the new version of perl without any errors.
>
> As Michael had warned, there were a huge number of packages that needed to have their rootfiles updated to reflect the change in version number that is in the directory path for many files.
>
> I have installed the iso, that resulted from my build, into my vm testbed and everything that I tested worked fine with no hiccups.
>From which version to which did you jump?
I would expect that some parts of the web UI are not compatible with newer versions of Perl.
> Next thing I will do is the commits for each changed package.
>
> My understanding is that for the common packages I only need to provide the changed rootfile in the patch but for the addons I have to update the PAK_VER number if the rootfile has changed so they will have a combination of lfs and rootfile in the patch.
Yes, please commit any changes of the LFS files and rootfiles of the same package together. We technically can probably not go back if something breaks in only one module, but this is then possible to rewiew in reasonable time.
> I will make the perl change into a series of patches, the primary one for perl and each other package will have its own patch.
Yes, there will be tons of dependencies and packages might bring perl bindings (e.g. rrdtool) which will need to be touched, too.
It might even be helpful for me to push the git branch somewhere so that I do not have to pull each patch separately :)
https://wiki.ipfire.org/devel/git/pull-requests
> This will mean that I will be sending a huge number of patches in to patchwork later today/tomorrow. If I should be doing this another way, because of the large number of packages in the series, let me know what I should do differently.
No, go ahead. I do not think there is a better or worse time for this :)
Thank you for putting all this time into this.
-Michael
>
>
> Regards,
>
> Adolf.
>
> --
> Sent from my laptop
>
next prev parent reply other threads:[~2021-04-01 9:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 8:31 Adolf Belka
2021-04-01 9:55 ` Michael Tremer [this message]
2021-04-01 11:32 ` Adolf Belka
2021-04-01 13:24 ` Michael Tremer
2021-04-01 16:51 ` Adolf Belka
2021-04-01 17:35 ` Michael Tremer
2021-04-01 21:07 ` Adolf Belka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2E2ADAC5-B4FF-4B9B-A087-364C08DBA048@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox