[Bug 904843] Review Request: acpica-tools - ACPICA tools for the development and debug of ACPI tables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=904843

--- Comment #10 from Michael Schwendt <mschwendt@xxxxxxxxx> ---
> 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

> 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}

[...]

> 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.


> 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

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

-- 
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=BXRnX5AmAK&a=cc_unsubscribe
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review



[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]