versioning question for stax-utils
by Andy Grimm
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
following situation:
* They have released in the past using date-based versions (20070216,
for example)
* 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.
Thanks.
Andy
11 years, 8 months
[Guidelines Change] Change to the Packaging Guidelines
by Tom Callaway
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.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
---
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:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
11 years, 8 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Here are the latest set of changes to the Fedora Packaging Guidelines:
---
A new section has been added to the SysV Initscripts section, discussing
the proper use of subsys locking. Even though Fedora packages should no
longer be using SysV Initscripts as a primary service mechanism, Red Hat
Enterprise Linux and EPEL do. Additionally,
Red Hat points partners to the Fedora Guidelines when they build for RHEL.
https://fedoraproject.org/wiki/Packaging:SysVInitScript#Careful_Handling_...
---
The review guidelines now reflect the use of sha256sum (instead of
md5sum) to confirm upstream source integrity.
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Things_To_Check...
---
The PHP Packaging guidelines have been updated to include guidance about
when it is appropriate to have an explicit Requires on httpd & mod_php,
how to handle explicit Requires on PHP extensions, and how to handle a
Requires for a minimum PHP version.
https://fedoraproject.org/wiki/Packaging:PHP#Apache_requirement
https://fedoraproject.org/wiki/Packaging:PHP#Extensions_Requires
https://fedoraproject.org/wiki/Packaging:PHP#Requiring_a_Minimum_PHP_version
---
A new section on Macros has been added to the Packaging Guidelines,
covering Packaging of Additional RPM Macros.
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_of_Addition...
---
A new section on the Documentation= field in systemd unit files (F17+)
has been added.
https://fedoraproject.org/wiki/Packaging:Systemd#Documentation_field
---
A short section on the Group tag in Fedora packages has been added.
All current versions of Fedora (and their respective RPM versions) treat
the Group tag as optional. Packages may include a Group: field for
compatibility with EPEL, but are not required to do so.
https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag
---
The RHEL conditionalization has been removed from the Python3 example
spec file, as it is no longer valid.
https://fedoraproject.org/wiki/Packaging:Python#Example_spec_file
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Remi Collet, David Malcolm, Vit Ondruch, Lennart
Poettering, Michael Scherer, Dave Sullivan, 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:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
11 years, 8 months
Re: [Fedora-packaging] [Guidelines Change] Changes to the Packaging Guidelines
by Peter Lemenkov
Hello All.
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.
>>
>> https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_of_Addition...
>
> 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
> configuration.
>
> Why not have this somewhere below /usr?
Agree. We should install them into /usr/lib/rpm.
--
With best regards, Peter Lemenkov.
11 years, 8 months