[Fedora-packaging] Re: [Bug 192912] Review Request: paps

[Michael Schwendt]

On Sat, 17 Jun 2006 02:51:05 +0200, Ralf Corsepius wrote:

> On Sat, 2006-06-17 at 01:03 +0200, Michael Schwendt wrote:
> > On Fri, 16 Jun 2006 10:02:25 -0500, Tom 'spot' Callaway wrote:
> > 
> > > > Yes. There exist packagers who (In FE devel)
> > > > * don't use %{?dist} at all
> > > > * some use N%{?dist} and increment N with each iteration.
> > > 
> > > These are correct...
> > > 
> > > > * some use N%{?dist}.M and increment M with each build-iteration 
> > > 
> > > ...and these are not. More bugs to file!
> > 
> > I disagree. It should be packager's freedom what to do in this
> > least-significant position of the release field.
> And I disagree, with this.
> 
> Conversely: This kind of "freedom" is the cause for a lack of
> simplicity, and the cause for the broken upstream path versioning errors
> being reported.
> With more restrictive conventions, these issues would not exist.
> 
> > If this style of bumping release versions were not permitted, we would see
> > more unneeded mass-rebuilds of a package for all dists only to keep the
> > upgrade path sane when a new build for only an older dist is needed.
> Why would that happen?

Because packagers would bump the most-significant portion of the release
field for _all_ dists and request builds for _all_ dists instead of only
updating a single older dist release.
 
> Make "N%{dist}.M" (w/ N,M ... int > 0) mandatory

Above you said this scheme is a bug. Now I'm confused.

I like and use N%{?dist}.M and the '0.' prefix for pre-releases.  I also
like the flexibility we get when we are permitted to move non-numerical
bits out of %{version} and place them in %{release} instead.

Our mission objectives:

 1 - sane upgrade path in Core
 2 - sane upgrade path in Extras
 3 - sane upgrade path between Extras -> Core
 4 - sane upgrade path between Core -> Extras

Additionally, for entirely new packages, not in Core/Extras before,
packagers may choose a suitable EVR which upgrades upstream packages. But
once the package is in Core/Extras, there must not be any unexpected or
confusing version changes, which bear the risk of creating a bad upgrade
path.

Note that the first two points are underestimated a lot, since preferably,
for CD/ISO based upgrades, RPM version comparison for packages ought to be
a strict

  FIRST_EVR(new_dist) > ALL_EVR(old_dist)

for any pair of dists and all update packages for old_dist. In our scheme,
this would be achieved by bumping the N in our N%{?dist}.M only with the
release of a new distribution and M inbetween. N would then be newer than
any N in any packge and an older dist.

> and drop the pre/post-release stuff.

Why drop the useful "post-release stuff" now, too?

> I don't see how epoch bumps would ever be needed.

E.g. when upstream's versioning scheme is incompatible with RPM's
versioning scheme, particularly with pre- or post-release non-numerical
pieces.