Subject: Re: [SM-Commit] RFC: Declarative DSL for applying patches [was: Re: GIT changes to master grimoire by Ismael Luceno (ebb3d4ea0344f74a552a75a2b3f4df78275aa44c)]
Date: Mon, 29 Aug 2016 19:48:29 +0200
Am Fri, 26 Aug 2016 17:52:10 -0300
schrieb Ismael Luceno <ismael.luceno AT gmail.com>:
> > OK, if it's not in the patches themselves, I would prefer a PATCHES
> > file, as it would make more explicit the info is processed in CONFIGURE
> > and PRE_BUILD.
Reasonable. Incidentally, that's how it is done in other packagers, too
(thinking about pkgsrc's PATCHES file, which just lists them, though).
> I've made a first attempt at defining a format of PATCHES:
> <label> <file> <options...>
>
> Lines starting with a space continue the previos one.
I'm not totally sure the whitespace continuation is good/safe. I'd
format it that way, yes, but perhaps the grammar should be more robust,
like simply always lines with a leading keyword.
patch spleeze
file spleeze.patch # could be autoconstructed from above
conflicts splooze
needs gtk+2 # wait, is that for other patches or spell dependencies?
desc A longer text explaining what it's for, perhaps
desc even multiple lines.
patch sploose
conflicts spleese # really necessary on both ends?
strip 2
> The "needs" and "conflicts" options would be processed by another
> function (select_patches?) to properly generate and order questions
> in the CONFIGURE stage.
Yeah. Once we got the logic settled. I'm in a hurry now … just wanted
to have some reply out …
> Order of application is order of appearance in the file.
Good to think about that and how flexible/complicated we want to make
it. FIFO may be sensible. Corner cases are corner cases (perhaps two
versions of a patch needed for complex optional combinations).