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.
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
