Mass changes to packaging

Scott Schmit i.grok at comcast.net
Thu Aug 23 00:29:36 UTC 2012


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:
> > Lennart Poettering <mzerqung at 0pointer.de> writes:
> > > On Wed, 22.08.12 09:25, Kevin Fenzi (kevin at scrye.com) wrote:
> > >> I'll add a me too here. 
> > >> 
> > >> Any word on if the macros can/will be back-ported to f16/f17? 
> > 
> > > The preset logic is actually already available in F17, so we could
> > > theoretically backport that, but this would mean we'd also have to
> > > create and maintain a preset policy file for F17, and that's the bit I
> > > am not sure i'd like to do.
> > 
> > > Without the preset policy the macros would only turn things off after
> > > installation, never on.
> > 
> > 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.

Another way to go is to create 2 macros for pre-F18 that are no-ops
F18+ and make the F18+ macros no-ops pre-F18. Then have packagers put
both in (or maintain two versions of the spec file).

It's kind of ugly, but it sounds like it's that or wait until F20 before
maintainers start picking up the new macros (unless they already have
different spec files per Fedora version).

HTH

-- 
Scott Schmit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4104 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120822/032a028b/attachment.bin>


More information about the devel mailing list