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]
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.(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.
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 :-)
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.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.* Avoid developer time being spent incrementing integers in spec fileThe 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.
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: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.
ReleaseStyle: (standard|manual|jpackage|prerelease|postrelease)[ ,]* \
(standard|manual|jpackage|prerelease|postrelease)
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?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.
* 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.
-1This 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.
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.* specfiles needing modification when built outside of the context of the build system.No, "make srpm" (and by extension "make local") continues to work.
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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
