On Fri, 2008-03-07 at 10:03 +0000, Kevin Kofler wrote:
> > * Allow for automated (re-)builds without hackish scripts
>
> The scripts we have work fine
I've been at Red Hat quite a long time now, and automated rebuilds have
been a problem that entire time. This problem is created by the spec
file trying to be a database of build IDs (Revision); there's no innate
reason rebuilding software has to be so painful.
There were still some problems even with the latest rebuilding script,
not because the script was wrong (AFAIK) but because following those
guidelines is very complicated in edge cases, and people get it wrong.
Another way to look at this is - one should never have files modified
both by humans and automated processes stored in revision control. If
you do, it's a recipe for pointless conflicts and pain.
> (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.
Yes, exactly! We implement it in one place, and don't give a chance for
humans to mess it up.
> > * 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.
The real thing this blocks is more automation in our processes. I don't
want to have to edit a spec file at all when a new release comes out; we
should have a system where I can look on a web page and see "New
upstream releases of foo, bar available", and click one link to pull
them in for tentative builds and tests, and then if that works tag them.
> > * 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.
Even with "make commit", there are still two separate changelogs, and
they will be out of sync. We really don't want more than one way to do
things.
> 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,
As I replied to Tom, these kinds of edge cases can be encoded in a
separate header in the spec, or probably even better in an improved
version of the "sources" file; see my replies to him and also below.
> then there's the branch-only fixes (*.fc*.*)
The build system can determine this automatically - remember, we have a
database of all builds. Again, one less thing for a human to mess up.
> and the
> JPackage-compatible versioning (*jpp.*.fc*) which are also in common use.
If we want that, it can be handled by a new header such as
"JpackageCompatibleRelease: yes".
> * in schemes like prereleases, how to define the prerelease tag ("alphatag") to
> use.
I like the idea for this one of extending the "sources" file - say a
third field which denotes whether a file is a pre or post release.
> * Release number inflation for no good reason (if we fix something in a build
> which failed, it doesn't need a new Release number).
But Release numbers right now aren't guaranteed to correspond to
anything at all. They often approximate the number of successful
builds, but...note that with the proposal to get rid of force-tag, you
will no longer be able to make Release correspond one to one with
successful builds even in our current system.
> * specfiles needing modification when built outside of the context of the build
> system.
No, "make srpm" (and by extension "make local") continues to work.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
