Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=904843 --- Comment #14 from Michael Schwendt <mschwendt@xxxxxxxxx> --- Oh, discussing Debian packaging practices is beyond the scope of a Fedora package review request. ;) I would also favour "more relaxed" Fedora packaging guidelines in a few areas, but with more freedom comes more responsibility, and simply adhering to package versioning guidelines makes it easier to avoid common pitfalls (such as violated dist-upgrade paths, desire to downgrade something, Epoch madness) and reinventing the wheel. [...] > Version: 5.0 You may consider the ACPI specification version relevant, but it is not being used for the versioning scheme of the acpica-unix archive. Where's the benefit? acixf.h #define ACPI_CA_VERSION 0x20130117 changes.txt 17 January 2013. Summary of changes for version 20130117: https://www.acpica.org/downloads/linux.php The current release of ACPICA is version 20130117. The tarball: acpica-unix-20130117.tar.gz http://rpmfind.net/linux/rpm2html/search.php?query=acpica https://bugs.launchpad.net/ubuntu/+source/acpica-unix/+bug/1060791 The Obsoletes/Provides pair now would be self-obsoleting Provides: iasl = %{version}-%{release} Obsoletes: iasl < 20120913-7 and would advertise a changed versioning scheme for iasl, too. > Release: 20130117.1%{?dist} So, I see you've returned to the official tarball release. You invent your own versioning scheme, with the real upstream version being part of the Release tag. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag It's also not as flexible as you might think. Imagine the need to release an update for an older dist. For ordinary package changes, you could only bump the Release tag at the very right side, Release: 20130117.1%{?dist} -> Release: 20130117.1%{?dist}.1 or else a package for Fedora 17 could become newer than a package for Fedora 18. That's described here: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches Even more so, if you ever wanted to use a new snapshot for an older dist only. With the date value at the most-significant position of the Release tag, you could not increase it without doing that also for all newer dists. rpmdev-bumpspec would need to be patched/enhanced, too, to understand this versioning scheme. For mass-rebuilds of Fedora packages, it would apply only the "minor release bump" to this package. Not pretty. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=XjemNYtbnv&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review