Update ImageMagick in Fedora 16

[Pavel Alexeev]

05.06.2012 16:09, Michael Schwendt wrote:
> On Tue, 05 Jun 2012 14:05:13 +0400, Pavel Alexeev wrote:
>
>> 04.06.2012 22:26, Michael Schwendt написал:
>>> On Mon, 04 Jun 2012 19:36:29 +0400, Pavel Alexeev wrote:
>>>
>>>> Additionally have worth I try read carefully all docs about
>>>> provenpackager and such updates and have not found how deal with such
>>>> versions.
>>> It's not provenpackager specific stuff, but found in the basic packaging
>>> guidelines:
>>>
>>> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag
>>>
>>>> I had look in my packages and few others and found it was
>>>> updated many times in that way.
>>> Just read the page linked above. There is no strict requirement to
>>> apply this release versioning scheme for old branches. If newer branches
>>> would always win RPM Version Comparison because their %version field
>>> is _higher_, you can bump %release in older branches without risk.
>>>
>>>> In packages were was present subrelease
>>>> after %{?dist} - I increase it.
>>>> Should or must in next time I add it in any package even it does not
>>>> have it??
>>> As the guidelines say: "Be careful with this!"
>> Thank you very much Michael. It's helpful.
>> But what still is not clear to me - if it secure, may it be applied to
>> all packages on update in stable releases? Or instead I should check if
>> increasing release do not break version sequence in branches - do that.
>> And only if it false, introduce subrelease like %{?dist}.1?
> Well, if you want to spare yourself the extra check, simply use the
> %{?dist}.N scheme for old branches _always_. Then you're on the safe side.
>
> [That means: If you see only a %{?dist} in an old branch, introduce the
> %{?dist}.N scheme even if it's not strictly necessary. If you see the
> %{?dist}.N scheme is used already, increase N appropriately. Then it's
> up to the package owner, or anyone else who touches the package, to
> check whether the normal %{?dist} scheme would be fine when preparing
> another bug-fix release sometime after you.]
>
Ok, thank you for the explanation.