Putting the new GConf Schema Guidelines into effect

[Toshio Kuratomi]

Hi guys,

The new GConf Schema Guidelines (
https://fedoraproject.org/wiki/GConf_Scriptlets_%28draft%29 ) have been
approved by FPC and ratified by FESCo.  In order to put them into effect
we need to get two files installed by some package.

* The /etc/rpm/macros.gconf file holds the rpm macros that hide the
implementation details of installing GConf schema.  These need to be
present when the rpm's of GConf using packages are built.
* The /var/lib/rpm-state/gconf directory holds temporary files that keep
state for GConf schema between the %pre and %post stages of the rpm
transaction.  This needs to be available at package install time.

To handle the macros file I think we should add them to
redhat-rpm-config.  Jon, is that fine with you?

To handle the state directory, I think GConf2 should own:
  %dir %{_localstatedir}/lib/rpm-state/gconf

Since nothing currently owns /var/lib/rpm-state, we probably want it
(and anything else that uses the directory in the future) to own:
  %dir %{_localstatedir}/lib/rpm-state
as well.

Does this seem like a good plan to everyone?  I can submit bugzilla
reports to track the changes going into packages and update the
Guidelines for the Fedora Releases where this feature becomes available
if this is good.

Also, FESCo asked if there was a plan to mass update all the packages.
Do you guys want to have that happen?  I told FESCo that the old way of
writing GConf install scripts was fine.  Just a bit slower and with more
text to write into every spec file.

-Toshio

[Jeremy Katz]

On Friday, June 12 2009, Toshio Kuratomi said:
> The /etc/rpm/macros.gconf file holds the rpm macros that hide the
>
> implementation details of installing GConf schema.  These need to be
> present when the rpm's of GConf using packages are built.
> The /var/lib/rpm-state/gconf directory holds temporary files that keep
>
> state for GConf schema between the %pre and %post stages of the rpm
> transaction.  This needs to be available at package install time.
>
> To handle the macros file I think we should add them to
> redhat-rpm-config.  Jon, is that fine with you?

Why not have the GConf2 package own it?  You'll have to have GConf2
installed first, so it would be there and feels like it would work okay

Jeremy

[Toshio Kuratomi]

On 06/12/2009 07:47 AM, Jeremy Katz wrote:
> On Friday, June 12 2009, Toshio Kuratomi said:
> > The /etc/rpm/macros.gconf file holds the rpm macros that hide the
> >
> > implementation details of installing GConf schema.  These need to be
> > present when the rpm's of GConf using packages are built.
> > The /var/lib/rpm-state/gconf directory holds temporary files that keep
> >
> > state for GConf schema between the %pre and %post stages of the rpm
> > transaction.  This needs to be available at package install time.
> >
> > To handle the macros file I think we should add them to
> > redhat-rpm-config.  Jon, is that fine with you?
>
> Why not have the GConf2 package own it?  You'll have to have GConf2
> installed first, so it would be there and feels like it would work okay

The macros are expanded at build time.  The GConf2 package is not
necessarily needed at build time (for instance, programs written in
python or another scripting language.)  Adding the macros to GConf2 and
adding BuildRequires: GConf2 to the Guidelines is an option.

I've talked to halfline on IRC and he's open to doing either.  Just
waiting on Jon Master's input.

[Toshio Kuratomi]

On 06/12/2009 07:43 AM, Toshio Kuratomi wrote:
> Also, FESCo asked if there was a plan to mass update all the packages.
> Do you guys want to have that happen?  I told FESCo that the old way of
> writing GConf install scripts was fine.  Just a bit slower and with more
> text to write into every spec file.

Talked to halfline on IRC and he's definitely for keeping updating of
spec files optional.  We're all hoping that file triggers can reach a
usable state and we can switch directly to those instead of having to
switch to macros first and file triggers later.  But there's also no
reason to stop packages from taking advantage of the macros.

Note that the performance gains from using the macros should be lower in
F12 than in previous releases as mclasen has improved the performance of
gconf in this area.

-Toshio

[Ville Skyttä]

On Friday 12 June 2009, Toshio Kuratomi wrote:
> Hi guys,
>
> The new GConf Schema Guidelines (
> https://fedoraproject.org/wiki/GConf_Scriptlets_%28draft%29 ) have been
> approved by FPC and ratified by FESCo.

Doesn't the GPLv2+ license of the macros mean that they can only be used by 
GPLv2+ (or compatible) packages?  If not, why not?  If yes, why not use the 
original author's LGPLv2.1+ license?

[Toshio Kuratomi]

On 06/12/2009 09:26 AM, Ville Skyttä wrote:
> On Friday 12 June 2009, Toshio Kuratomi wrote:
> > Hi guys,
> >
> > The new GConf Schema Guidelines (
> > https://fedoraproject.org/wiki/GConf_Scriptlets_%28draft%29 ) have been
> > approved by FPC and ratified by FESCo.
>
> Doesn't the GPLv2+ license of the macros mean that they can only be used by 
> GPLv2+ (or compatible) packages?  If not, why not?  If yes, why not use the 
> original author's LGPLv2.1+ license?

Thanks for catching that!  I don't know about the legality of using the
macro in compatible packages but the GPLv2+ was either a typo or a
misread on my part.  I've fixed the page to have LGPLv2+ as the original
author did.

-Toshio

[Enrico Scholz]

Toshio Kuratomi  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

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.

Enrico

[Toshio Kuratomi]

On 06/12/2009 01:49 PM, Enrico Scholz wrote:
> Toshio Kuratomi  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

[Nicolas Mailhot]

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.

[Toshio Kuratomi]

On 06/13/2009 02:12 AM, Nicolas Mailhot wrote:
> 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.

I think you're missing what's being discussed here.  We're talking about
whether to macroize the Requires lines or not.  Nothing about file
triggers in this leaf of the discussion.

-Toshio

[Enrico Scholz]

Toshio Kuratomi  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