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: Thu, 12 Aug 2021 16:37:00 +0100 Message-ID: In-Reply-To: <3ea3988517b265a62cc91f6a0382e50b0e465fcb.camel@disroot.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7177018540694267747==" List-Id: --===============7177018540694267747== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Robin, > 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 ? Did it make it on the list? I thought there were some outstanding emailing is= sues. > 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 Jo= nathan's comments about de pakfire code quality which I originally duplicated= in a previous prototype of the changes to come.) We currently have a massive backlog of changes that are being merged. We are shipping massive core updates that become almost impossible to test an= d we have added loads of regressions that have not been resolved, or are bein= g shipped months after they have been fixed. So I would like to spend more ti= me on structuring changes and test, test, test! -Michael >=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 --===============7177018540694267747==--