[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: NVR bugs in rawhide



On Wed, 15 Jul 2009 01:50:44 +0200, Ralf wrote:

> Michael Schwendt wrote:
> > On Tue, 14 Jul 2009 17:54:10 +0200, Ralf wrote:
> > 
> >> Michael Schwendt wrote:
> >>> On Tue, 14 Jul 2009 16:01:50 +0200, Ralf wrote:
> >>>
> >>>>> You don't need to drop %dist for koji build inheritance to work.
> >>>>>
> >>>>> It just looks much cleaner to inherit foo-1.0-1.noarch.rpm for all
> >>>>> newer targets
> >>>> IFF "current rpm" is sufficiently compatible to the antique version of 
> >>>> rpm a package has been built on.
> >>>>
> >>>> If this doesn't apply you don't get anywhere.
> >>> Not _with_ %dist either.
> >> Of cause it would help. A package's release tag would very verbosely 
> >> tell you that a package is outdated.
> > 
> > And still it would fail if RPM were changed [the way you describe] while
> > %dist stayed the same. 
> Right, the key being using %?dist is _rebuilding_.

It's insufficient. %dist alone doesn't tell anything about ABI
compatibility or compatibility of products/packages in general.
Further, when you need to mass-rebuild more than once you cannot
rely on %dist. And because %dist changes too slowly, you still need
to bump %release whenever you rebuild something.

[Theoretically, when %dist changes, one could create new cvs tag
_without_ committing an increased %release tag, but this is not what has
been done so far, as such rebuilds would not have a %changelog entry,
for example.]

> > %dist doesn't reflect at all whether RPM changes
> > its file format near the beginning of a Fedora devel cycle.
> Right, but unlike hidden build dates etc. it is clearly _visible_.

Still, it's not accurate enough to jump to conclusions about whether
a package needs a rebuild or not.
 
> >>>> => I agree with Jussi. Allowing people not to use %dist is not helpful. 
> >>>> It's a booby trap which certainly will hit some day.
> >>> %dist is a trap itself - packagers run into it regularly, e.g. when
> >>> adding Obsoletes and versioned dependencies, when doing trial-and-error
> >>> fixing of old branches (without paying attention to the recommendations in
> >>> the guidelines), when committing and tagging after a server-side update of
> >>> the "branches" file.
> >> Quite easy to overcome: always use %?dist.
> > 
> > Doesn't help much. Packager still needs to bump all branches [correctly]
> > to recover.
> Not true. He needs to rebuild rawhide, not all branches.

The tag for F[N-1] %dist is occupied by "devel" cvs, so clearly it's
necessary to bump'n'rebuild at least _two_ branches after the "cvs up
common". (if you don't want to cheat and build the F[N-1] pkg from the
tag on the "wrong" cvs dir)

The problem is not specific to using %dist, but with packages where using
%dist doesn't add any value (e.g. those where %version makes big jumps
only during the devel period), you are unlikely to run into it anyway.

Probably we can end this thread. I'm aware of the small benefit of using
%dist for src.rpm pkgs that shall be copied to multiple target branches in
cvs _without modification_. That's the only thing where %dist aids the
packager. It doesn't "fix" anything else. [It doesn't wipe out upgrade
path problems either, just think about that please before making a rushed
reply.] Using %dist isn't safe (or "more safe") than not using %dist.
There are pitfalls.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]