Re: Pacman behaviour comparing numerical versions for package upgrades

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



On Fri, Jun 29, 2012 at 1:02 AM, Angel Velásquez <angvp@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 29/06/12 02:58, Allan McRae wrote:
>> On 29/06/12 15:50, Myra Nelson wrote:
>>> I have a question about pacman's behaviour regarding packges to
>>> be updated.
>>>
>>> According to < $: man pacman >
>>>
>>> You can also use pacman -Su to upgrade all packages that are out
>>> of date. See Sync Options below. When upgrading, pacman performs
>>> version comparison to determine which packages need upgrading.
>>>
>>> Alphanumeric: 1.0a < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc <
>>> 1.0 < 1.0.a < 1.0.1 Numeric: 1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 <
>>> 3.0.0
>>>
>>> That's very clear and makes sense. Here's where I'm confused. I
>>> build some of my perl pacakges with cpanpkgbuild -f
>>> XXX::XXX::YYY. The package from the official repos is:
>>> perl-datetime-format-strptime-1.5000-1-any.pkg.tar.xz
>>>
>>> the package I built is:
>>> perl-datetime-format-strptime-1.51-1-any.pkg.tar.xz
>>>
>>> I'm used to the warning package ??? local is newer than extra
>>> ???. But with the above referenced package I had to list it in
>>> the [ IgnorePkg ] line to keep pacman from trying to upgrade the
>>> package and still get this warning.
>>>
>>> "Ignoring upgrade from perl-datetime-format-strptime from 1.51-1
>>> to 1.5000-1"
>>>
>>> No complaints as it's easy to fix, I was just wondering about
>>> the reasoning. I'll jump out on a limb here and assume it's
>>> because the repo package has 4 digits then the package version
>>> after the decimal point and my package has two digits then the
>>> package version after the decimal point. The developer changed
>>> his numbering scheme after 1.5000 to 1.51.
>>>
>>> Is this the correct behaviour for pacman?
>>>
>>
>>
>> 5000 > 51
>>
>>
>>
>
> Yes, some perl packages had that versioning schema, which is
> confusing.. that said, it's not a pacman bug.
>
> - --
> Angel Velásquez
> angvp @ irc.freenode.net
> Linux Counter: #359909
> http://www.angvp.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJP7UTaAAoJEEKh2xXsEzutrPcH/iRPp7SyqtS3XfSfnVq0qXGh
> 1ubC97p0LT3S2umtB3EojJ5HOCOvkCMCtASflSJW7yeCcv3jiExhSh2R0riQ2d29
> 3K/56Vhf0hMeNz3OJMgoUVgMicI4ulbWRswERXQqmd27WCqN1odMDJo6x564uC/9
> sALz0wVPkqi5fdxtAStoUBIUaQl7OLsv9EdP9OZrttjvN6SmZfN5LQMWvK0qBMfz
> Y+5a2zT8LmkmUPvMO2VUBC9X9LvtALGPmsUILXzohXdJpjIRE3QsFUmQz1Ie98Vb
> Pio4Fk5GIcRmsv6hJZicYVXGHpkyZGUgYImIWDeWu1OAAdaaHqEs9+BU3yYslA8=
> =m/KC
> -----END PGP SIGNATURE-----

Angel:

I didn't think it was a pacman bug, "Bugs? You must be kidding, there
are no bugs in this software", I was making sure I hadn't screwed
something up along the way when I built my package. I should have
added "Or did I screw something up?".

Myra
-- 
Life's fun when your sick and psychotic!


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux