Neal Hogan wrote:
On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute <> 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.

Adam Vandemore
Systems Administrator
IMED Mobility
(605) 498-1610

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to