Scott Schmit <i.grok(a)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(a)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