From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: perl update notification Date: Thu, 01 Apr 2021 10:55:25 +0100 Message-ID: <2E2ADAC5-B4FF-4B9B-A087-364C08DBA048@ipfire.org> In-Reply-To: <0d924e08-858e-abb3-b56a-33405b981209@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5539140495632718857==" List-Id: --===============5539140495632718857== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 1 Apr 2021, at 09:31, Adolf Belka wrote: >=20 > Hi All, >=20 > After a lot of work I have successfully built the new version of perl witho= ut any errors. >=20 > 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. >=20 > I have installed the iso, that resulted from my build, into my vm testbed a= nd 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 ve= rsions of Perl. > Next thing I will do is the commits for each changed package. >=20 > 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_VE= R number if the rootfile has changed so they will have a combination of lfs a= nd rootfile in the patch. Yes, please commit any changes of the LFS files and rootfiles of the same pac= kage 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 p= erl and each other package will have its own patch. Yes, there will be tons of dependencies and packages might bring perl binding= s (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 patchw= ork later today/tomorrow. If I should be doing this another way, because of t= he large number of packages in the series, let me know what I should do diffe= rently. 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 >=20 >=20 > Regards, >=20 > Adolf. >=20 > --=20 > Sent from my laptop >=20 --===============5539140495632718857==--