[Fedora-packaging] Re: Putting the new GConf Schema Guidelines into effect

[Nicolas Mailhot]

Le vendredi 12 juin 2009 à 17:40 -0700, Toshio Kuratomi a écrit :

> <nod>  So, is this where we want to go with Scriptlets and macros in the
> future?  Currently the Guidlines specify explicit Requires.  However, as
> long as we're macroizing scriptlets, we could macroize the Requires as
> well.  However, this makes people more reliant on the specific recipes
> in the Guidelines without understanding what's going on and how they can
> either change them to suit a slightly strange package or adapt them to
> work for a new type of script.  For an imperative construct like the
> scriptlet, there's a complicated, bit of shell being abstracted behind
> the macro,  copy and paste errors there could be hard to detect.  The
> Requires are more standard which makes them harder to get wrong and
> easier to see what's wrong on visual inspection.

There is no reason that for the magic implementation to be different if
it's called implicitelly instead of explicitelly.

Using file triggers won't make the thing that adds code to the spec
magically better or more reliable. It won't magically rewrite it in
another language by a better coder. All it will do is hide the whole
process from packagers so if there *are* cut and paste errors they won't
even know the code with cut & paste errors was called.

Now, what could be done is to reduce the enveloppe to adding to the
spec:
1. a buildreq on whatever includes the macro
2. the macro call itself

and then have the macro itself inject requirements as-needed in the spec
file.

Note that:
1. requires enhancing rpm macro support (you can't inject reqs unless
the macro call is in the req part of the spec right now)
2. defining a special kind of buildreq category that mocks pulls in
before evaluating what needs to end up in the build root (otherwise
macro-injected buildreq are not expanded at build root creating)

As for errors when cut and pasting macro calls, they're not worse than
other cut and paste errors. There's no reason for some magic implicit
auto-call trigger to be more reliable.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20090613/f4a9b6b1/attachment.sig>