spec file changes: removing Release: and %changelog
Toshio Kuratomi
a.badger at gmail.com
Fri Mar 7 16:51:33 UTC 2008
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>
More information about the fedora-devel-list
mailing list