On 06/12/2009 01:49 PM, Enrico Scholz wrote: > Toshio Kuratomi <a.badger@xxxxxxxxx> writes: > >> The new GConf Schema Guidelines ( >> https://fedoraproject.org/wiki/GConf_Scriptlets_%28draft%29 ) > > It would be easier to define an additional macro > > | %gconf_requires \ > | Requires(pre): GConf2 \ > | Requires(preun): GConf2 \ > | Requires(post): GConf2 \ > | %nil > <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. OTOH, if the macros change in the future, for instance Requiring: GConf3 to run, then abstracting the Requires: can save a bit of spec updating there. Although the BuildRequire that pulls in the macro would still need to be updated, so we're not saving that in all situations. Possibly a tangent: The scripts that this was adapted from had a %gconf_requires type macro. However, it was wrong. It added scriptlets for %post, %preun, etc like we do but only had Prereq: GConf2. Not sure if peer review would have caught that had it not been hidden behind a truly superfluous macro or if more cut and paste errors would have resulted. > > which is used like > > | BuildRequires: <package-which-provides-your-macros> > | %{?gconf_requires} > > in your .spec file. > > > > >> To handle the macros file I think we should add them to redhat-rpm-config. >> Jon, is that fine with you? > > A separate package (perhaps GConf2-devel?) would be better. > Why would it be better? Note, that I'm not persuaded one way or the other. I just want to assemble what the pros and cons are. The only con I can see is that you have to BuildRequire: GConf2-devel for this to work. Also is there a benefit to using GConf2-devel instead of GConf2? For scripting languages, GConf2-devel will pull in C development packages that aren't otherwise needed. Which seems to be a con for using GConf2-devel instead of GConf2. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
