Re: portupgrade -o strangeness...
On Tue, Jun 12, 2007 at 11:23:34AM +0100, Alex Zbyslaw wrote:
> 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?
I didn't try separate options for -f and -o. I've always just ran
single-letter options together and never had any issues. I'd be surprised if
that were the problem.
I ended up going back to portupgrade from portupgrade-devel and everything
seemed to work fine.
Thanks,
Josh
--
Josh Tolbert
[EMAIL PROTECTED] || http://www.puresimplicity.net/~hemi/
Security is mostly a superstition. It does not exist in nature, nor
do the children of men as a whole experience it. Avoiding danger
is no safer in the long run than outright exposure. Life is either
a daring adventure, or nothing.
-- Helen Keller
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade -o strangeness...
Josh Tolbert wrote:
On Fri, Jun 08, 2007 at 12:04:38PM +0100, Alex Zbyslaw wrote:
Josh Tolbert wrote:
(15:38:21 <[EMAIL PROTECTED]:~>) $ pkg_info | grep bison
bison-1.75_2,1 A parser generator from FSF, (mostly) compatible with
Yacc
(15:38:30 <[EMAIL PROTECTED]:~>) $ sudo portupgrade -o devel/bison2 bison
(15:38:34 <[EMAIL PROTECTED]:~>) $ 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?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade -o strangeness...
On Fri, Jun 08, 2007 at 12:04:38PM +0100, Alex Zbyslaw wrote: > Josh Tolbert wrote: > > >(15:38:21 <[EMAIL PROTECTED]:~>) $ pkg_info | grep bison > >bison-1.75_2,1 A parser generator from FSF, (mostly) compatible with > >Yacc > >(15:38:30 <[EMAIL PROTECTED]:~>) $ sudo portupgrade -o devel/bison2 bison > >(15:38:34 <[EMAIL PROTECTED]:~>) $ 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. :) 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. Ironically, portupgrade still does things right. portupgrade-devel is the port I'm having problems with. Thanks, Josh -- Josh Tolbert [EMAIL PROTECTED] || http://www.puresimplicity.net/~hemi/ Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. -- Helen Keller ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
portupgrade -o strangeness...
Hello, Having successfully completed my update from Xorg 6.9 to Xorg 7.2, I decided to install a few things, one of which required devel/bison2 instead of bison. Usually, portupgrade -o would handle this for me, but lately it seems like portupgrade -o doesn't want to replace ports. Has anyone else noticed this or is there a known workaround/fix? (15:38:21 <[EMAIL PROTECTED]:~>) $ pkg_info | grep bison bison-1.75_2,1 A parser generator from FSF, (mostly) compatible with Yacc (15:38:30 <[EMAIL PROTECTED]:~>) $ sudo portupgrade -o devel/bison2 bison (15:38:34 <[EMAIL PROTECTED]:~>) $ sudo portupgrade -fo devel/bison2 bison ---> Reinstalling 'bison-1.75_2,1' (devel/bison) The same problem occurred when I tried to replace ghostscript-gnu with ghostscript-gpl as well. I'm using portupgrade-devel instead of portupgrade. Thanks, Josh -- Josh Tolbert [EMAIL PROTECTED] || http://www.puresimplicity.net/~hemi/ Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. -- Helen Keller ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
