Re: [PATCH 0/2] buildprocess: additional pak metadata

[Robin Roevens <robin.roevens@disroot.org>]

[-- Attachment #1: Type: text/plain, Size: 5692 bytes --]

Hi

Michael Tremer schreef op vr 13-08-2021 om 10:18 [+0100]:
> Hello,
> 
> > On 12 Aug 2021, at 19:28, Robin Roevens <
> > robin.roevens(a)disroot.org
> > > wrote:
> > 
> > Hi Michael
> > 
> > Michael Tremer schreef op do 12-08-2021 om 16:37 [+0100]:
> > > Hello Robin,
> > > 
> > > > On 12 Aug 2021, at 16:34, Robin Roevens <
> > > > robin.roevens(a)disroot.org
> > > > >
> > > > wrote:
> > > > 
> > > > Hi all
> > > > 
> > > > 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 issues.
> > 
> > Yes, it did the second try. Also recorded by patchwork:
> > https://patchwork.ipfire.org/project/ipfire/list/?series=2178
> > 
> 
> Okay. It looks like I missed it then. No problem.
> 
> > > > 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.)
> > > 
> > > We currently have a massive backlog of changes that are being
> > > merged.
> > > 
> > > 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!
> > 
> > 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’t matter. There will be
> a merge conflict which will be trivial to solve.
> 
Actually all LFS files for pak's are changed in my patch (198 at the
time of submitting my patch) by adding a SUMMARY and a SERVICES
variable to them. And where applicable the call to INSTALL_INITSCRIPT
was changed to INSTALL_INITSCRIPTS,$(SERVICES) .

> > 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 the time to have things on the list for him to grab them.
Ok, I will then try to review my patch against master again this
evening..

Regards
Robin

> 
> -Michael
> 
> > Regards
> > Robin
> > 
> > > -Michael
> > > 
> > > > Regards
> > > > 
> > > > Robin
> > > > 
> > > > Robin Roevens schreef op do 01-07-2021 om 21:15 [+0200]:
> > > > > Hi
> > > > > 
> > > > > Second attemt to submit this patchset. Hoping the mailserver
> > > > > won't
> > > > > find
> > > > > malicious URLs in it.
> > > > > 
> > > > > For completeness, the summary included in the first attempt:
> > > > > 
> > > > > As discussed earlier, I hereby submit a patchset adding extra
> > > > > metadata 
> > > > > to all pak's.
> > > > > 
> > > > > First patch adds the new metadata fields "Summary" and
> > > > > "Services"
> > > > > to
> > > > > the 
> > > > > meta-file templates and introduces the new macro
> > > > > INSTALL_INITSCRIPTS 
> > > > > 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 
> > > > > them).
> > > > > The original INSTALL_INITSCRIPT macro is kept (and called by
> > > > > the
> > > > > new
> > > > > macro) for corner cases where non-service initscripts need to
> > > > > be 
> > > > > installed and for use by non-pak lfs files as they currently
> > > > > don't
> > > > > have 
> > > > > a SERVICES variable. 
> > > > > 
> > > > > The second patch adds the new metadata for all pak's in their
> > > > > respective
> > > > > lfs files. 
> > > > > 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.
> > > > > 
> > > > > 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.
> > > > > 
> > > > > Regards
> > > > > 
> > > > > Robin
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Dit bericht is gescanned op virussen en andere gevaarlijke
> > > > inhoud door MailScanner en lijkt schoon te zijn.
> > > > 
> > > 
> > > 
> > 
> > 
> > -- 
> > Dit bericht is gescanned op virussen en andere gevaarlijke
> > inhoud door MailScanner en lijkt schoon te zijn.
> 
> 
> 


-- 
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.