Colin Walters <walters <at> redhat.com> writes:
> I pretty clearly listed the problems - do you disagree that they are
> problems, or that this approach will solve them?
I disagree that they are problems:
> * Allow for automated (re-)builds without hackish scripts
The scripts we have work fine (there was only one issue discovered during the
GCC 4.3 mass rebuilds, which was with the *jpp.*.fc* scheme, and that has
already been fixed), and if you want maintainers to uniformly accept your
automated Release tag generation, you will have to implement the exact same
release bumping schemes those scripts implement.
> * Avoid developer time being spent incrementing integers in spec file
That's usually a 1-character change, sometimes a 2-character change, it takes
10 seconds at worst, I fail to see the problem there.
> * Obviate the need to keep two changelogs in sync
That's solved by a one (middle) click paste or by solutions like "make clog" or
the proposed "make commit". I don't see the real problem there either.
> * Resolve clashes about what disttags should be by having them
> determined by the build system
%{?dist} is universally agreed as the standard these days (except for the cases
which don't need a disttag at all, like huge noarch binaries of data which are
just untarred and need no compilation at all, so they can just be carried over
from release to release) and it's clear what it expands to.
> * Longer term, make it easier to transition to a better source format
Removing only Release and %changelog from the specfile won't change much there.
In addition, I think your approach creates new unsolved problems which have
already been mentioned:
* how to pick the versioning scheme to use: at least prerelease packages need a
special scheme, then there's the branch-only fixes (*.fc*.*) and the
JPackage-compatible versioning (*jpp.*.fc*) which are also in common use.
* in schemes like prereleases, how to define the prerelease tag ("alphatag") to
use.
* Release number inflation for no good reason (if we fix something in a build
which failed, it doesn't need a new Release number).
* specfiles needing modification when built outside of the context of the build
system.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
