Toshio Kuratomi <a.badger(a)gmail.com> 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