[Bug 782560] Review Request: rubygem-ruby-shadow - *nix Shadow Password Module
bugzilla at redhat.com
bugzilla at redhat.com
Wed Feb 15 14:29:57 UTC 2012
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=782560
--- Comment #5 from Todd Zullinger <tmz at pobox.com> 2012-02-15 09:29:56 EST ---
(In reply to comment #4)
> Well, the guidelines for obsoleting are pretty clear, so it should really be
> the way I mentioned in comment2.
I'm not sure I see where that would be the case. The guidelines I am reading
are from
http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
and state, in part:
Example: foo being renamed to bar, bar is compatible with foo, and the last
foo package release being foo-1.0-3%{?dist} with Epoch: 2; add to bar (and
similarly for all subpackages as applicable):
Version: 1.0
Release: 4%{?dist}
Provides: foo = 2:%{version}-%{release}
Obsoletes: foo < 2:1.0-4
Following that, the last ruby-shadow release was 1.4.1-15%{?dist}, with no
epoch. I still believe that the proper obsoletes/provides entry is:
Obsoletes: ruby-shadow < 1.4.1-16
Provides: ruby-shadow = %{version}-%{release}
After looking more, obsoletes for ruby(shadow) are not needed at all, as a
newer ruby(shadow) provides will already be added as a matter of normal ruby
packaging process. That name isn't changing, so the obsoletes is not required.
The important part that requires Obsoletes/Provides here is ruby-shadow, as
that is the old package we're replacing.
Am I missing something?
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the package-review
mailing list