[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 #15 from Al Stone <ahs3@xxxxxxxxxx> ---
(In reply to comment #14)
> Oh, discussing Debian packaging practices is beyond the scope of a Fedora
> package review request. ;)

Agreed :-).

> [...]
> 
> > 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?

My thinking was it would aid the user.  However, given that the ACPI
spec has never been in the versioning _before_, I can concede on that
point.  It doesn't really add that much.

> 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

Hrm.  Fair enough.  It would make it more difficult to find things
across distros; I had not considered that part of it.

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

Yup.  Examining the changes in git vs the official tarball in more detail,
they were not sufficient to justify going to a snapshot type of package.
They were useful patches, but "nice to have" not "essential to working
properly."  The benefit was far outweighed by the effort for the snapshot
scheme.

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

Yes, I did, with the thought that it might be more useful (I seek to
continuously improve things whenever I can...).  In this case, though, the
counter-arguments so far have had more weight -- and more practicality that
I had not seen before.  I've learned a great deal :).

So let's just use the original straightforward scheme.  I can work with
that.  That would be:

   Version: 20130117
   Release: 1%{?dist}

which should handle the Obsoletes/Provides, as well.

-- 
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=to2f8F38qn&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]