nealhogan at gmail.com
Fri Mar 20 15:04:01 PDT 2009
In light of Adam's comment and thinking about the comment he's responding
to, I realize that I may have been rather obnoxious. I appreciate Adam
setting that aside to give me and the list some of his time. I'm rather new
to fBSD (obvious) and I've got my parent's machine on it, which is hundreds
of miles away and they have put in requests that led me to upgrade their
system, including ports (and when X gets messed up from a remote position,
it can be frustrating). So, I apologize if my comments came across in such a
way that annoyed you. Not being a dev (or anywhere close), I have little
room to act that way.
But, I wonder what the most efficient way is to update ports. I appreciate
Adam's point about the fact that portupgrade (and portmanager and
portmaster) are ports themselves and are going to not be as reliable as what
is in base. However, the fBSD documentation on updating ports (i.e., the
handbook) only suggests the above three as ways to update ports. Is there a
way to update ports from a base app? Given that a basic setup will have
quite a few ports (hundreds), I was wondering if there was another way to
update all (including their dependencies), rather that a one-by-one *make
update* or *portupgrade*.
On Fri, Mar 20, 2009 at 12:23 PM, Adam Vandemore <amvandemore at gmail.com>wrote:
> 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
>>>> 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
>>> $ 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,
>> 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
>> 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
>> have upgrades fail. Please don't take my tone to be anything other than
>> coming from a sense of curiosity. I don't mean to suggest anything about
>> fBSD ports system. Perhaps my experience is the result of my own
>> 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
>> dependencies are "taken care of."
>> As I write this I am running portupgrade individually, on those ports
>> 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
>> that are not up-to-date.
>> I could see if ports failed to upgrade or were ignored due to there being
>> 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
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions