FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 06-29-2012, 06:35 AM
Florian Pritz
 
Default Pacman behaviour comparing numerical versions for package upgrades

On 29.06.2012 07:50, Myra Nelson wrote:
> The developer changed his numbering scheme after 1.5000
> to 1.51.

In that case you should add epoch=1 to the PKGBUILD.

--
Florian Pritz
 
Old 06-29-2012, 06:51 AM
Myra Nelson
 
Default Pacman behaviour comparing numerical versions for package upgrades

On Fri, Jun 29, 2012 at 1:03 AM, Allan McRae <allan@archlinux.org> wrote:
> On 29/06/12 16:01, martin kalcher wrote:
>> Am 29.06.2012 07:58, schrieb Allan McRae:
>>> On 29/06/12 15:50, Myra Nelson wrote:
>
>>>> * * *"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
>>
>> So we dont need this:
>>
>>>> I'm used to the warning package ??? local is newer than extra ???.
>>
>
> Just to be clear:
>
> pacman sees 1.5000 as being newer than 1.51 as 5000 > 51. *So that
> warning is correct, because only perl package versioning thinks that
> 5000 < 51 ...
>
> Allan

Allan:

Thanks. That was my assumption, but as engineers like to say "When you
assume something you make an ass out of u and me.

Myra

--
Life's fun when your sick and psychotic!
 
Old 06-29-2012, 06:57 AM
Myra Nelson
 
Default Pacman behaviour comparing numerical versions for package upgrades

On Fri, Jun 29, 2012 at 1:02 AM, Angel Velásquez <angvp@archlinux.org> 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
> 1ubC97p0LT3S2umtB3EojJ5HOCOvkCMCtASflSJW7yeCcv3jiE xhSh2R0riQ2d29
> 3K/56Vhf0hMeNz3OJMgoUVgMicI4ulbWRswERXQqmd27WCqN1odMD Jo6x564uC/9
> sALz0wVPkqi5fdxtAStoUBIUaQl7OLsv9EdP9OZrttjvN6SmZf N5LQMWvK0qBMfz
> Y+5a2zT8LmkmUPvMO2VUBC9X9LvtALGPmsUILXzohXdJpjIRE3 QsFUmQz1Ie98Vb
> Pio4Fk5GIcRmsv6hJZicYVXGHpkyZGUgYImIWDeWu1OAAdaaHq Es9+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!
 
Old 06-29-2012, 07:09 AM
Myra Nelson
 
Default Pacman behaviour comparing numerical versions for package upgrades

On Fri, Jun 29, 2012 at 1:35 AM, Florian Pritz <bluewind@xinu.at> wrote:
> On 29.06.2012 07:50, Myra Nelson wrote:
>> The developer changed his numbering scheme after 1.5000
>> to 1.51.
>
> In that case you should add epoch=1 to the PKGBUILD.
>
> --
> Florian Pritz
>
>
>

Florian:

Thanks for the tip.

Myra

--
Life's fun when your sick and psychotic!
 
Old 06-29-2012, 08:30 AM
Cédric Girard
 
Default Pacman behaviour comparing numerical versions for package upgrades

On Fri, Jun 29, 2012 at 8:03 AM, Allan McRae <allan@archlinux.org> wrote:

> pacman sees 1.5000 as being newer than 1.51 as 5000 > 51. So that
> warning is correct, because only perl package versioning thinks that
> 5000 < 51 ...
>

I suggest you to have a look at this thread as well:
https://mailman.archlinux.org/pipermail/aur-general/2011-February/013512.html

Regards,
--
Cédric Girard
 
Old 06-29-2012, 11:50 AM
Thomas Bächler
 
Default Pacman behaviour comparing numerical versions for package upgrades

Am 29.06.2012 07:50, schrieb Myra Nelson:
> 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.

Dan once told me that pacman uses the same version comparing algorithm
that rpm uses (and deb probably uses the same). Just saying that we
didn't invent it, but it is de-facto standard.
 
Old 06-29-2012, 10:28 PM
Myra Nelson
 
Default Pacman behaviour comparing numerical versions for package upgrades

On Fri, Jun 29, 2012 at 6:50 AM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 29.06.2012 07:50, schrieb Myra Nelson:
>> 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.
>
> Dan once told me that pacman uses the same version comparing algorithm
> that rpm uses (and deb probably uses the same). Just saying that we
> didn't invent it, but it is de-facto standard.
>

Thanks to everyone for your responses. Allan and Florian cleared up
any misconceptions I had. I read the section in <man pacman> about
using epoch=1 for such situations but it didn't register, hence my
question. I rebuilt the packaged with epoch=1 and the message turned
to perl???? local is newer than perl??? repo.

@Thomas

This is why I love Arch. It helps one learn things that you never
would have found out using other distributions.

Myra

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

Thread Tools




All times are GMT. The time now is 12:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org