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

[Michael Tremer <michael.tremer@ipfire.org>]

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

Hello,

> On 13 Aug 2021, at 11:49, Robin Roevens <robin.roevens(a)disroot.org> wrote:
> 
> 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) .

That should not cause any trouble I think.

>>> 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..

Please rebase against “next”.

-Michael

> 
> 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.