[quagga-dev 12670] Re: Building RPMs for Redhat 6 or 7 (or CentOS 6 or 7)
gdt at ir.bbn.com
Tue Jun 9 14:11:55 BST 2015
Andrew Gideon <andrew-quagga-dev-726 at tagonline.com> writes:
> I found that the SPEC file was somewhat out of date for Redhat or CentOS
> versions 6 and 7. I've updated it.
> There are branches:
> * volatile/andrew/addingrhel7support_0.99.24
> * volatile/andrew/addingrhel7support
> available in http://quagga.git.tagonline.com/quagga.git where the first
git times out, and the host does not answer ping.
> extends adds the commits to the stable/0.99.24 branch and the latter to
> master. I hope I've followed the convention for this naming properly.
> HACKING didn't seem to have anything about feature branch naming, but I
> noticed the use of "volatile/..." in other cases.
Thanks for actally reading HACKING :-) You are right that the feature
branch names aren't specified clearly, but they don't matter much.
> HACKING did specify extending master. I added the branch extending
> stable/0.99.24, though, since that's the branch I happen to be using at
> the moment (and at least one other person on quagga-users has tried this
This does seem to be an unusual situation.
> Unfortunately, the SPEC file fixes were insufficient to have master work
> for RPM building. Another issue arose as of commit
> d8d54ab78d915921a88a8707426e307aed3c323e. In that commit, the version
> tag in configure.ac became "0.99.25-dev". The dash is rejected by
> rpmbuild (where it is used for @VERSION@ in quagga.spec.in), presumably
> because a dash is a field separator in RPM file names.
I don't use rpms, but I suspect - is problematic in most packaging
systems. but in general (not about quagga) I think the version number
world has become a complete mess with all sorts of languages and
projects inventing new conventions and (implicitly) expecting N
packaging systems to support them. But, the notion of versions for
branches rather than releases is messy anyway.
> I took the easy solution of changing this to a tilde, and added that to
> branch volatile/andrew/avoidDashInVersionID which further extends
> master. I'm not sure that this is the desirable approach. I believe it
> does have the advantage, though, that:
> 0.99.25~dev < 0.99.25
> to RPM's version ordering.
This is not just about RPM, but about deb, pkgsrc, FreeBSD ports, and
other systems. Do you know of a specification for version numbers that
is broader than one packaging system and is generally agreed on? My
own bias is to revert to the ancient GNU standards and call it
0.99.24.80 (80 is reserved for alpha and 90 for beta, in that scheme).
The other thought is that generally packaging systems only package
releases, not git versions, and if they do package git they need to have
a date or something else. So the fact that the rpmbuild of git fails is
not necessarily a problem.
There has also been some notion of removing the rpm files from quagga's
sources, on the theory that they are maintained externally by packagers.
The pkgsrc control files are not in quagga, but some ancilliary scripts
are. I know many different Linux distributions use rpm, so it has
seemed to me that removing them would be a net increase in work among
the entire Free Software community.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 180 bytes
Desc: not available
More information about the Quagga-dev