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

[Enrico Scholz]

Toshio Kuratomi <a.badger at 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