spec file changes: removing Release: and %changelog

[Toshio Kuratomi]

Colin Walters wrote:
> On Fri, 2008-03-07 at 10:03 +0000, Kevin Kofler wrote:
> 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.

[snip]

>> (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.
> 
Errr... Read the guidelines again.  That is a valid tag due to java 
packagers having made the case that there is a need to interleave with 
jpackage.  If the buildsystem were to make the release tag up it would 
have to decide whether the packager wanted to stay interleavable with 
jpackage and if so find out what the present jpackage version-release is 
and build our release tag from that.

Or you can try to convince the Java Packagers that interleaving with 
jpackage is not a desirable thing... but we've already been through that 
once so you better have some good arguments :-)

>>> * 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.
> 
That would be nice.  It would also have to check that the configure 
script hasn't changed beyond the package's version update (for autoconf 
using build systems... not sure that other build systems will accurately 
capture build requirements in one spot :-( ).  Otherwise, you silently 
go without a new optional feature because configure didn't find it at 
build time.

> 
>> 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.
> 
But then you're right back to specifying release information in the spec 
file :-(.  (It's more elegant in that it's not encoding the build order 
in the spec but it's still annoying to the packager as they have to add 
it to the file when things change.)  Implemented wrong, it also could be 
a special case to be used and then forgotten... Having the header always 
present would be good:
ReleaseStyle: (standard|manual|jpackage|prerelease|postrelease)[ ,]* \
     (standard|manual|jpackage|prerelease|postrelease)

>> 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.
> 
Err... it can determine that the last build was a branch-only build but 
how can it determine that the current build is a branch only build?

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

This is one of the differences between Debian dpkg and rpm that I like 
about rpm.  All the build information is in one file.  Our current 
sources file is generated automatically and never needs to be edited by 
the package builder.  It is only there so the buildsystem can 
differentiate between two tarballs that have the same name.

>> * specfiles needing modification when built outside of the context of the build 
>> system.
> 
> No, "make srpm" (and by extension "make local") continues to work.
> 
You're both right.  make srpm could be enhanced to do something 
approaching correct.  But just taking the spec file out of Fedora's cvs 
and attempting to build it won't work any longer.  You no longer can 
build with just rpmbuild, a spec, and a tarball.  You need the Fedora 
Makefiles as well.

Also, btw, your make local doesn't do the right thing WRT disttag. 
disttag is supposed to tell which distribution the package is built for, 
not which repo it is built by.  So disttag == .fc8 means the package was 
built for and intended to run on Fedora 8.  .local is a repotag rather 
than a disttag.  Additionally, whatever it expands to should sort lower 
than the equivalent Fedora package built in the buildsystem.  Otherwise 
you, the package maintainer, have extra steps to perform to go from 
testing your local built package to testing the package built on the 
buildsystem.  (Whereas if it sorts lower, the buildsystem package is 
picked up by the normal yum update).

I like the ideas for change that you're putting out here but not 
necessarily the implementations :-).  Things that can be done from 
within the spec file to affect the buildsystem are vastly preferable to 
me as our current model is that the srpm is the basic, indivisible unit 
that we want to work with.

If you don't see a way to work within that constraint then we as a 
project need to evaluate whether we want to continue to base ourselves 
on the srpm or if we're going to move to a new format as our base (with 
the possibility of generating srpms as an intermediate format).  We 
might take half-steps like you propose to get there but we need to 
decide that that's the direction we want to head.

-Toshio


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080307/1c6188b7/attachment.sig>