From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/2] buildprocess: additional pak metadata
Date: Fri, 13 Aug 2021 10:18:41 +0100 [thread overview]
Message-ID: <FDD798AD-D968-40C0-BF3A-E69BDFC206A4@ipfire.org> (raw)
In-Reply-To: <e0d7a6e5d62395b1d727f26729eccaf235ffe1f8.camel@disroot.org>
[-- Attachment #1: Type: text/plain, Size: 4558 bytes --]
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.
> 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.
-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.
next prev parent reply other threads:[~2021-08-13 9:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-01 19:15 Robin Roevens
2021-07-01 19:15 ` [PATCH 1/2] buildprocess: Add extra metadata to meta-* files Robin Roevens
2021-07-01 19:15 ` [PATCH 2/2] buildprocess: Add extra metadata to pak lfs files Robin Roevens
2021-08-12 15:34 ` [PATCH 0/2] buildprocess: additional pak metadata Robin Roevens
2021-08-12 15:37 ` Michael Tremer
2021-08-12 18:28 ` Robin Roevens
2021-08-13 9:18 ` Michael Tremer [this message]
2021-08-13 10:49 ` Robin Roevens
2021-08-13 11:19 ` Michael Tremer
[not found] <1b25db163f59f5f89796a05b7d97ab2098eb230d.camel@disroot.org>
2021-07-01 8:31 ` Michael Tremer
2021-07-01 19:31 ` Robin Roevens
-- strict thread matches above, loose matches on Subject: below --
2021-06-24 22:50 Robin Roevens
2021-06-24 23:04 ` Robin Roevens
2021-06-26 12:09 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FDD798AD-D968-40C0-BF3A-E69BDFC206A4@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox