amvandemore at gmail.com
Fri Mar 20 10:23:18 PDT 2009
Neal Hogan wrote:
> On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute <frank at shute.org.uk> wrote:
>> On Thu, Mar 19, 2009 at 03:21:05PM -0500, Neal Hogan wrote:
>>> The last couple of days I've been running portupgrade -av and am to the
>>> point where I'd like to move onto something else, but there is one
>>> that won't upgrade . . . xorg-server. As you can see below, it claims
>>> there is a missing header and there are a fair amount of reported errors.
>>> I'm not the best at deciphering the stuff below.
>>> I've tried make deinstalling/reinstalling and individually portupgrading
>>> to no avail.
>>> glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or
>> $ pkg_info -W /usr/local/include/GL/internal/dri_interface.h
>> /usr/local/include/GL/internal/dri_interface.h was installed by package
> I wish to not only that Frank for his patience and subtle hand-holding, but
> also address the rest of the list.
> First, concerning the issue Mr. Shute responded to . . .
> I reinstalled xf86driproto, which installed the dri_interface.h, which
> allowed me to pkg_add xorg-server. However, it was the older version of
> xorg-server. So, I ran portupgrade on it and it, again, claims that there is
> no dri_interface.h. According to pkg_version, all xorg and xf86 ports are
> up-to-date, except xorg-server of which there is a newer version.
> That said, I was hoping that you can help me understand the portupgrade
> process b/c it can be a bit frustrating when it runs for a LONG time only to
> have upgrades fail. Please don't take my tone to be anything other than one
> coming from a sense of curiosity. I don't mean to suggest anything about the
> fBSD ports system. Perhaps my experience is the result of my own oversight.
> Just to be clear, here are the steps I took:
> 1) #portsnap fetch
> 2) #portsnap extract
> 3) #portsnap update
> 4) #pkgdb -u
> 5) #pkgdb -F
> 6) #portupgrade -av
> As I noted in another post, some ports fail to upgrade when using
> portupgrade -a, no matter how many times it is run. However, they (those
> that fail), along with their dependencies, do upgrade when portupgraded
> individually (or de/reinstalled). I thought the purpose of having a ports
> system, where you install the ports tree and use portupgrade, was to make
> the install/upgrade easy and rather painless, such that all ports and their
> dependencies are "taken care of."
> As I write this I am running portupgrade individually, on those ports that
> failed to upgrade with -a option, but have (so far) succeeded in upgrading
> individually. I am simply looking at the output of pkg_version to find those
> that are not up-to-date.
> I could see if ports failed to upgrade or were ignored due to there being no
> diff between what's installed and that which is in the updated tree.
> Can someone shed some light on this? Thanks a lot for taking the time.
Part of the issue is that portupgrade is not a core part of the freebsd
ports. It is itself a port, an addon that adds in it own set of
complexities -- see it's man page. It's a wonderful utility but not
perfect. When I run into issues using portupgrade, I find it easiest to
fix what failed using standard port tools, not an addon, then resume the
portupgrade after I fixed errors manually. Generally the process is
relatively quick, but on something big like kde4 it can take quite
awhile. As for specific events, you can post the errors and someone
should be able help like before. Another rule of thumb I use is that I
don't use portupgrade -a on system with a massive graphical enviro
installed....too many areas to fail. So in a situation like yours I
might start with a portupgrade -Rf xorg-server and see how far it gets.
Once completed, I'll go onto other major apps to upgrade until I get to
the end. There may certainly be better ways to handle, just what I've
found works best for me.
1) portsnap fetch update
2) portupgrade -Rf xorg-server
Should really be all you need to do to upgrade it. portupgrade will
automatically detect stale entries and do the pkgdb -u and tell you if
you need to run pkgdb -F.
Other options like pre-fetching, config recursive, and ignoring errors
can also help save time. Used incorrectly, ignoring error can
significantly increase time though.
More information about the freebsd-questions