From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH 0/2] buildprocess: additional pak metadata Date: Fri, 13 Aug 2021 10:18:41 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8030931432846348719==" List-Id: --===============8030931432846348719== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 12 Aug 2021, at 19:28, Robin Roevens wrote: >=20 > Hi Michael >=20 > Michael Tremer schreef op do 12-08-2021 om 16:37 [+0100]: >> Hello Robin, >>=20 >>> On 12 Aug 2021, at 16:34, Robin Roevens >>> wrote: >>>=20 >>> Hi all >>>=20 >>> Had anybody already had a chance to start reviewing this patch-set >>> during my absence ? >>=20 >> Did it make it on the list? I thought there were some outstanding >> emailing issues. >=20 > Yes, it did the second try. Also recorded by patchwork: > https://patchwork.ipfire.org/project/ipfire/list/?series=3D2178 Okay. It looks like I missed it then. No problem. >>=20 >>> I also have changes to Pakfire in the pipeline to actually use the >>> metadata provided by this set, but I'm waiting to submit those >>> patches >>> as they depend on the acceptance of this set (and on my >>> other patch "pakfire: implement function to parse meta files" to >>> counter Jonathan's comments about de pakfire code quality which I >>> originally duplicated in a previous prototype of the changes to >>> come.) >>=20 >> We currently have a massive backlog of changes that are being merged. >>=20 >> We are shipping massive core updates that become almost impossible to >> test and we have added loads of regressions that have not been >> resolved, or are being shipped months after they have been fixed. So >> I would like to spend more time on structuring changes and test, >> test, test! >=20 > I understand. It's a bit unlucky that this patch then was not applied > before all those changes, as those changes will probably require me to > review my patch again against all changes made to pak's in the > meantime. What packages have changed? If a package has been dropped or so this won=E2=80=99t matter. There will be = a merge conflict which will be trivial to solve. > So I'll try to keep an eye on when next core is submitted and then > review and resubmit my patchset. Arne is currently working on putting the next Core Update together. Now is th= e time to have things on the list for him to grab them. -Michael > Regards > Robin >=20 >>=20 >> -Michael >>=20 >>>=20 >>> Regards >>>=20 >>> Robin >>>=20 >>> Robin Roevens schreef op do 01-07-2021 om 21:15 [+0200]: >>>> Hi >>>>=20 >>>> Second attemt to submit this patchset. Hoping the mailserver >>>> won't >>>> find >>>> malicious URLs in it. >>>>=20 >>>> For completeness, the summary included in the first attempt: >>>>=20 >>>> As discussed earlier, I hereby submit a patchset adding extra >>>> metadata=20 >>>> to all pak's. >>>>=20 >>>> First patch adds the new metadata fields "Summary" and "Services" >>>> to >>>> the=20 >>>> meta-file templates and introduces the new macro >>>> INSTALL_INITSCRIPTS=20 >>>> accepting a space seperated list of initscripts to install to >>>> avoid >>>> duplicating the list of service initscripts. (Once in the new >>>> SERVICES >>>> meta-data field and once by calling INSTALL_INITSCRIPT for each >>>> of=20 >>>> them). >>>> The original INSTALL_INITSCRIPT macro is kept (and called by the >>>> new >>>> macro) for corner cases where non-service initscripts need to be=20 >>>> installed and for use by non-pak lfs files as they currently >>>> don't >>>> have=20 >>>> a SERVICES variable.=20 >>>>=20 >>>> The second patch adds the new metadata for all pak's in their >>>> respective >>>> lfs files.=20 >>>> As I went over all pak lfs files, I did not encounter any corner >>>> cases >>>> hence all calls to INSTALL_INITSCRIPT are replaced by calls to >>>> the >>>> new >>>> INSTALL_INITSCRIPTS passing the SERVICES variable as argument. >>>> The only special case maybe worth mentioning is Icinga, where a >>>> service >>>> initscript is installed by a make rule of the source. Hence no >>>> call >>>> to >>>> INSTALL_INITSCRIPT or INSTALL_INITSCRIPTS is required. But the >>>> service >>>> is included in the SERVICES variable to have it recorded in the >>>> meta- >>>> file. >>>>=20 >>>> This set does not yet contain changes in pakfire or services.cgi >>>> to >>>> actually do something with the new meta-data. >>>> Those changes will be posted shortly. >>>>=20 >>>> Regards >>>>=20 >>>> Robin >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Dit bericht is gescanned op virussen en andere gevaarlijke >>> inhoud door MailScanner en lijkt schoon te zijn. >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. --===============8030931432846348719==--