mcdouga9 at egr.msu.edu
Thu Dec 17 12:45:24 UTC 2009
On Thu, Dec 17, 2009 at 10:21:02AM +0100, Jimmy Renner wrote:
Quoting Mark Linimon <linimon at lonesome.com>:
> On Wed, Dec 16, 2009 at 11:13:36PM -0500, Robert Huff wrote:
>> The maintainer, ruby@, is aware of this; a check of the PR
>> database shows multiple open PRs, none critical but many serious
>> going back six months and more.
> As an aside, the Severity and Priority fields have been so often abused
> as to have become meaningless. Although I still try to groom the db
> for "critical" ones, and thus try to get those some attention, I really
> don't think the committers pay much attention. (In general I think
> those should be reserved for "data corruption" and "security".)
> The longer-term solution is to remove those as user-settable fields.
>> This hard to understand given portupgrade is the recommended upgrade
> Once the individual who was working on it gave it up to the mailing
> list, it became one of those "everyone is responsible so no one is
> responsible" problems. I don't have a recommended fix for this.
> Having said that, I have a ports tree as of a month ago and portupgrade
> was working ok for me. I don't have the cycles to go figure out where
> it fails to be able to fix it, sorry.
I don't know if your issues are related but yesterday I managed to fix
a ports tree that made portupgrade crash. I wasn't aware that
portupgrade looks in the options files for dependencies. I think some
ports, and my guess it is those who gave me the problem, blindly pulls
in dependencies without checking if they are already installed or not
and it is in those cases that portupgrade can get an incorrect cyclic
Some of that sounds true to my experience, for a while I've noticed while
installing a new port with portupgrade that it will install the default
dependencies before prompting with the options screen to find out which
ones I want. For example if I do 'portupgrade -N postfix' on a fresh
system, it will first install pcre and THEN prompt me to (de)select pcre
or any of the other optional deps.
Ok, enough of my strange unproven theories. I removed a lot of the
options files from /var/db/ports/... and after some point, it was
actually when removing them from all the p5-* ports, portupgrade
started working again. When running portupgrade again I was more
restrictive with what options to actually enable and after that
Don't know if that will help anyone but I though I should at least put
my ideas down somewhere.
This message was sent using IMP, the Internet Messaging Program.
freebsd-ports at freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
More information about the freebsd-ports