Hi, all. I have a package up for review, and there's some question
about how it should be versioned. The package is stax-utils (
https://bugzilla.redhat.com/show_bug.cgi?id=794923 ), which has the
* They have released in the past using date-based versions (20070216,
* The POM files which I was able to find (this is a java package but
does not bundle its own POM) use the date-based version.
* I'm pulling the latest version from the subversion repository,
because I need something newer than the last stable release.
* There's nothing in the source tree to indicate a version at all
The pieces of data that I have to use in a version-release string are
the date: 20110309 and the svn revision: 238. I think the correct
thing here would be to call it 20110309-0.1.svn238 , which indicates
that it's a "pre-release" of 20110309, even though this specific
version is unlikely to ever be released. Does this make sense?
Part of what's in debate here is that the package guidelines indicate
that the date should be in the release tag, but this seems redundant,
and there appears to be precedent (apache-commons-csv, batik, vpnc,
etc.) for omitting it.
Here is one late change to the Fedora Packaging Guidelines:
The systemd scriptlet guidelines have been updated for Fedora 18. In
Fedora 18, the systemd package now provides helper macros to simplify
%post, %preun, and %postun invocations in packages with systemd unit
files. Additionally, these macros enable support for systemd "profiles",
a Fedora 18 Feature.
This guideline change was approved by the Fedora Packaging
Committee (FPC), but was delayed until recently, pending Feature
approval of the systemd "profiles" feature.
Many thanks to Lennart Poettering, and all of the members of
the FPC, for assisting in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
In the interests of balance, there are costs to changing things:
- Documentation becomes obsolete and has to be rewritten.
- People have to be retrained.
- People have to relearn tasks that they know how to do now.
- Fedora becomes incompatible with other Linux and Unix (BSD etc) distros.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
2012/8/3 Lennart Poettering <mzerqung(a)0pointer.de>:
> On Wed, 01.08.12 15:28, Tom Callaway (tcallawa(a)redhat.com) wrote:
>> A new section on Macros has been added to the Packaging Guidelines,
>> covering Packaging of Additional RPM Macros.
> What's the rationale behind having these in /etc? This is hardly user
> configuration, and only ever used if people build their own RPMs. We
> really should try harder not to clutter /etc with stuff that is not
> Why not have this somewhere below /usr?
Agree. We should install them into /usr/lib/rpm.
With best regards, Peter Lemenkov.