Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Jun 2007 11:23:34 +0100
From:      Alex Zbyslaw <xfb52@dial.pipex.com>
To:        Josh Tolbert <hemi@puresimplicity.net>
Cc:        questions@FreeBSD.org
Subject:   Re: portupgrade -o strangeness...
Message-ID:  <466E7426.3060905@dial.pipex.com>
In-Reply-To: <20070612034110.GA95034@just.puresimplicity.net>
References:  <20070607204129.GA45269@just.puresimplicity.net> <466937C6.1010306@dial.pipex.com> <20070612034110.GA95034@just.puresimplicity.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Josh Tolbert wrote:

>On Fri, Jun 08, 2007 at 12:04:38PM +0100, Alex Zbyslaw wrote:
>  
>
>>Josh Tolbert wrote:
>>
>>    
>>
>>>(15:38:21 <hemi@demon:~>) $ pkg_info | grep bison
>>>bison-1.75_2,1      A parser generator from FSF, (mostly) compatible with 
>>>Yacc
>>>(15:38:30 <hemi@demon:~>) $ sudo portupgrade -o devel/bison2 bison
>>>(15:38:34 <hemi@demon:~>) $ sudo portupgrade -fo devel/bison2 bison
>>>--->  Reinstalling 'bison-1.75_2,1' (devel/bison)
>>>
>>>
>>>      
>>>
>>Have you tried "sudo portupgrade -f -o devel/bison2 bison" in case it's 
>>some bug in parsing merged options?  Worth a PR in any case...
>>
>>Failing that you could just pkg_delete bison and install bison2 afresh.  
>>You shouldn't have to but...
>>
>>--Alex
>>    
>>
>
>Hi Alex,
>
>Yes, I did exactly that. Take a look at the example above. :)
>  
>
It doesn't look like what I was suggesting is the issue so it's all 
moot, but the example I can see:

    sudo portupgrade -fo devel/bison2 bison

is different from what I was suggesting:

    sudo portupgrade -f -o devel/bison2 bison

which deliberately split -f and -o.  Your original version could reasonably be expected to work, but I have seen software (even written some :-)) which does not correctly parse flags when they are combined ("-fo") especially when one of them also takes an argument. That's not what's happening here, but my suggestion was always a shot in the dark.

>Anyway, a PR has been filed and the response is, "it's a feature." I'm not
>sure how it's a feature, but it is. The example I was given looks like this:
>
>$ pkg_version -t 2.3_1 1.75_2,1
><
>
>I'm guessing it's just doing some odd string comparison instead of breaking
>the version number apart and handling it with weight on the major version
>number, etc.
>  
>
I find it bizarre too,  since I don't even understand *why* the version 
numbers matter in that command line.  You've said "upgrade using 
devel/bison2" as the origin and it's upgrading using "devel/bison".  I 
could understand the version number bizarre-matching affecting *whether* 
portupgrade chooses to upgrade (so requiring -f) but not that it fails 
to honour the origin you've given.

The pkg_version comparison is surely just wrong.  The version numbers 
look correct to me.  Interestingly, if you drop the ,1 from the second 
version, the answer is correct (on 5.4 anyway).

$ pkg_version -t 2.3_1 1.75_2
 >

Or add a comma to the first

$ pkg_version -t 2.3_1,1 1.75_2,1
 >


which looks like a bug to me, but maybe there's something non-standard 
about that version number.  Blowed if I can see what; there are plenty 
of examples like it in my installed packages.

There's definitely a bug in something.

Software, bah.

--Alex

PS Presumably deinstalling bison and installing bison2 worked OK as a 
workaround?







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?466E7426.3060905>