portupdate xorg-server

RW rwmaillists at googlemail.com
Sat Mar 21 10:04:52 PDT 2009

On Sat, 21 Mar 2009 00:39:31 -0500
Adam Vande More <amvandemore at gmail.com> wrote:

> RW wrote:
> >
> > IMO this doesn't make any sense. If portupgrade is failing on a port
> > where manual "make install" works, then portupgrade simply has a
> > bug. Any port upgrading tool belongs in a port, because it's more
> > important that it responds to changes in the ports system than
> > changes in the base system. 
> >
> > As to upgrading piecemeal rather than with -a, I don't see how that
> > helps, and it may actually make things worse by not building in
> > dependency order.
> > _______________________________________________
> >
> >   
> As to the first part of your msg, what you said doesn't make any
> sense to me either.  Never did I claim portupgrade fails where a
> normal make install would succeed.  I would appreciate it if you
> could take my example as I state it instead adding stuff to make it
> sound implausible. 

And I would appreciate it if you actually read what I posted before you
accuse me of making things up.

My reply wasn't to your email it was to Neil Hogan, who did say that.

> Also
> after you get some experience in ports, you'll be able to understand
> that you can't depend on it compiling all the time. 
>   Hope that clears up the confusion for you.

Since you are the one that sees problems, and I find the whole thing to
be generally straightforward, I don't really think you are in a
position to be condescending. 

Many problems that are seen after a portupgrade -R will go away after
after a "portupgrade -a", so why waste time in debugging them. In my
experience a failed "portupgrade -a" scarcely ever leads to runtime
problems and most build problems are resolved after running csup.

Personally I don't find fault-finding signifiantly harder after a
"portupgrade -a" than after a "portupgrade -R"  YMMV.

The really important thing is to read UPDATING, but if you don't update
frequently enough you can run into a state where it's difficult to
conflate the entries into a single recipe.  If I ever let things slide
to the point where I was faced with two really complex metaport updates,
I *might* be tempted to take the tree back to the point when the first
update stablised and do them sequentially in that way.

More information about the freebsd-questions mailing list