Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=904843 --- Comment #12 from Al Stone <ahs3@xxxxxxxxxx> --- (In reply to comment #10) > > On f18, if I do "yum list iasl", I get 20100528-6. > > > Could you please explain the "too low" part? > > Sure. You somehow miss the %{?dist} macro at the end of the Release tag. The > value the macro expands to is not ignored during RPM version comparison: > > # rpm --eval %dist > .fc19 > > # yum list iasl|grep ^iasl > iasl.x86_64 20120913-6.fc19 > rawhide > > # rpmdev-vercmp 20120913-6.fc19 20120913-6 > 20120913-6.fc19 > 20120913-6 Whups. Thanks. I was missing the obvious part (the use of %dist). > > what should the version be? > > Either "<=" the latest EVR from Rawhide or "<" the next higher Release > value, i.e. either > > Obsoletes: iasl <= 20120913-6.fc19 > or > Obsoletes: iasl < 20120913-7 > > [...] > > > Provides: iasl > 20120913-6 > > Very unusual. Rather: > Provides: iasl = %{version}-%{release} Aha. Right. I didn't think that through properly. Many thanks for the explanation. > [...] > > > I will need to do is provide a patch to the pmtools > > package so that they also use alternatives > > Ah, that makes sense, of course. Cool. Thanks. > > > This is indeed a snapshot, so the version is now 20130123git, > > For a snapshot, you would need to adhere to the following guideline > > https://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control > > | There are several cases where upstream is not providing the source > | to you in an upstream tarball. In these cases you must document how > | to generate the tarball used in the rpm either through a spec file > | comment or a script included as a separate SourceX:. > > because the URL you've constructed results in "404 not found", as well as > the Packaging Naming Guidelines for snapshot packages (which Antonio has > pointed at): > > Version: 20130117 Aha. I'm used to Debian packaging which is a little more relaxed in this regard. > Which is the last official release of the source tarball, because typically > one doesn't "make up" own Version numbers, even if it may be possible to > predict the next version. And > > Release: 1.20130123git%{?dist} > > to apply Fedora's naming guidelines for post-release snapshot packages: > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Post- > Release_packages > > Alternatively, if you would insist on predicting the next officially > released version, you could apply the pre-release snapshot naming guidelines > (which isn't prettier however because for newer snapshots you would change > also the Version tag, not just the Release): > > Version: 20130123 > Release: 0.1.20130123git%{?dist} > > There, for updates of the package, you would bump the "0." and/or the > snapshot date. For a future officially released tarball, you would update > Version and reset Release back to "1%{?dist}". > > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages > | > | If the snapshot package is considered a "pre-release package", > | you should follow the guidelines listed in Pre-Release Packages > | for snapshot packages, > > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre- > Release_packages Hrm. Stepping back a second and rethinking the versioning, it is not critical to have the latest version from git (nice, but not critical). I think it would better to drop this and go to something that might convey more useful info to the user; the upstream git doesn't really change all that often, either (usually just at release time anyway). What upstream does is release a version supporting a specific release of the ACPI specification (5.0, in this case). Then, they periodically update the implementation (changing the date in the tarball name). So, my first thought was to do something like this: Version: 5.0 Release: 1.20130117%{?dist} and increment the 1. at the beginning of Release for each packaging change and/or bug fix required, similar to what was suggested above. If I need to pull something from git, do it as a patch and carry the patch until the next official release tarball. At the next tarball, reset the release back to 1.<date>. Unfortunately... $ rpmdev-vercmp 5.0-7.20130117.fc18 5.0-1.20130217.fc18 5.0-7.20130117.fc18 > 5.0-1.20130217.fc18 However, this approach compares properly: Version: 5.0 Release: 20130117.1%{?dist} $ rpmdev-vercmp 5.0-20130117.7.fc18 5.0-20130217.1.fc18 5.0-20130117.7.fc18 < 5.0-20130217.1.fc18 When the ACPI 6.0 specification comes out, 5.0 -> 6.0. When a new official tarball comes out, 20130117 -> the new date. If a packaging fix or a new patch is needed, .1 -> .2, and so on. I'll prepare rpm's with this scheme and post them. Let me know what you think. My sense is that this approach is just a lot more straightforward and I was making things more complicated than need be without gaining anything by it. -- 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=XGwSqIcXR9&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review