On Fri, 2004-12-17 at 23:55 +0100, Dries Verachtert wrote:
Do you mean the Release tag or the Version-Release of a spec file
with 'the
rpm revision number'?
I mean the Release and Version tags.
If i'm correct, you suggest to remove the release or the
version-release
completely from the spec file.. this would make it impossible to build the
spec file with a 'rpmbuild -ba bla.spec'.
Indeed. You would need to specify something like this:
rpmbuild -ba --version '1.2-4' bla.spec
Longer term, I think what we really want is a better way to branch
packages and maintain them, and to sync with the upstream packager. So
if you wanted to customize say the Fedora httpd RPM, you'd create your
own build database, etc. This would require a distributed RCS too.
What about adding default tags like
'Release: 1' which gets replaced by the build system of Fedora Extras?
That could work I guess, but then people might be tempted to bump the
Release tag. Better to just have people specify it at build time I
think and remove that temptation.
Such tags can be changed by the Fedora Extras buildsystem before it
starts a
rebuild of a spec file, no? I'm also doing something like that with my
self-made mini buildsystem: the last commit revision of that spec file is
added automatically to the first changelog entry.
Yeah, that screws merging. Better to just dump the changelog from the
spec.
This makes it possible to check automatically which spec files are
already
built for a certain distro/arch and which are not because i can compare the
svncmtid of the binary rpms with the current version of a spec file in the
subversion repository.
I think you're abusing the revision control system as a generic
database; better to use a real SQL database for this. Then you can add
additional metadata such as which package versions pass test suites, are
released for which distributions, etc.