Toshio Kuratomi <a.badger@xxxxxxxxx> writes: >>> 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. They are already wrong/incomplete ;) > 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. The Requires: depend on the implemention of the macro. E.g. all of the current ones have an additional dependency on 'coreutils', the %gconf_schema_upgrade requires 'diffutils' too. Hence, when macros change the Requires: might need also to be changed. Coding them as a macro would adopt changes/fixes without an action of the packager. >>> 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? I just do not think that it is a good idea to put special stuff into a general package. People who maintain the gconf macros are probably not the redhat-rpm-macros maintainer and there would be some bureaucracy when gconf macros need to be changed. Putting all used macros into one package does not scale very well. > 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? The rpm macros are not needed for GConf core functionality but only used for package building/developing. When people want a 'GConf2-rpm-macros' package, this would be ok with me (although I think that this is overkill). There might be used virtual provides for the macro stuff; e.g. package with macros.gconf has | Provides: rpm-macros(gconf) and packages with gconf files have | BuildRequire: rpm-macros(gconf) > 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. I do not care about lightweighted -devel packages, but main packages should provide their functionality only. Nowadays, tools like 'mock' are used for building rpm packages. There is no need to install -devel on production systems where gcc might be unwanted. Enrico -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
