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

Re: spec file changes: removing Release: and %changelog

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 
* 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 

        Kevin Kofler

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