libnet update to 1.1.6 coming to rawhide, soname bump
by Jon Ciesla
This affects the following:
libnids
suricata
syslog-ng
Whose owners are CCd and which I'll handle rebuilding unless the
owners would rather.
Thanks,
-J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
12 years
- 2
- 1
Git post-release version-release
by Alec Leamas
My problem is about possible ways to form the version-release fields for
a git post-release.. My example involves a version like 1.1.0 and a git
release like 20120329git1234567
Reading [1], all examples of post-release updates are on the form
foo-1.1.0-1.20120328git1234567.fc16. Obviously, this is one way to do it.
However, when I try to read the link carefully, I also see a possibility
to use a version-release like foo-1.1.1.20120328git1234567-1.fc16. My
reasoning based on the link:
- Version tags are either properly ordered or not.
- git tags like this are properly ordered (thanks to the date prefix).
- For properly ordered tags, the text explicitly says the tag can go
into the version field. However, there are no such examples.
Of course, another question is why. In short, I see some minor
advantages w r t robustness and consistency using this form. But for
now, this is not really the focus of this question.
So, my question: Reading [1], is a version-release like
foo-1.1.0.20120329git1234567-1.fc15 OK?
[1]:http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Post-Release_...
12 years
- 2
- 1