Neal Hogan wrote:
On Thu, Mar 19, 2009 at 4:15 PM, Frank Shute <fr...@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
package
that won't upgrade . . . xorg-server. As you can see below, it claims
that
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
it
to no avail.
suggestions?
glxdriswrast.c:39:39: error: GL/internal/dri_interface.h: No such file or
directory
$ pkg_info -W /usr/local/include/GL/internal/dri_interface.h
/usr/local/include/GL/internal/dri_interface.h was installed by package
xf86driproto-2.0.3
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.
-Neal
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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
