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
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
