Mass changes to packaging

[Tom Lane]

Scott Schmit <i.grok at comcast.net> writes:
> On Thu, Aug 23, 2012 at 01:22:27AM +0200, Lennart Poettering wrote:
>> On Wed, 22.08.12 19:17, Tom Lane (tgl at redhat.com) wrote:
>>> What I would want to see in F16/F17 is macros that exactly duplicate the
>>> previously-standard snippets they are supposed to replace.  Nobody is
>>> suggesting that the preset stuff ought to go into the released branches;
>>> only that we don't want to have to maintain different specfile versions
>>> for the different branches.  And if these things are macros, we should
>>> not have to.

>> The thing is that previously we had to different snippets, one for
>> enabling a service after installation, one for leaving it disabled. With
>> the macros there is only one which checks the preset policy whether
>> something should be enabled. Hence we can't really map the old logic to
>> the new macros, I fear.

> Well, you could have two macros -- pre-F18 they do what they do now,
> F18+, they do the same thing and defer to the policy.

Yeah.  The plain macros could be the non-auto-enable snippets, which
is what the majority of services will be.  Then a different macro
name for services that think they should auto-enable.

TBH I think that is probably a better design than what is there now,
because the ground truth for the default enable decision *ought* to be
in the packages, and this is as good a way to express that as any.
Setting things up so that the packages have no say in this is just
going to be a maintenance headache long-term: whoever is "in control
of the policy" is going to be deluged with this that and the other
change request.  It would be a whole lot more maintainable if the
"policy" only had to express deltas off the per-package defaults,
and not contain every single decision.

			regards, tom lane