Jon Drews wrote:
> In FreeBSD to correctly update you should do:
> 
>   # portupgrade -arR 
> the -a says update all the existing packages
> the -r says update all the packages that depend on the given package.
> the -R updates all the packages required by the given package.
> 
> Why do you have to use -r -R when -a is given? Because there may be
> new dependencies that  have to included.
>   The point is that if FreeBSD packages (ports)  are updated properly
> you will indeed run up against the same problem. With a large set of
> software, such as Kde or Gnome, you end up reinstalling a lot.

You don't need -rR to get new dependencies. New dependencies are picked up since 
the port depending on them will have it's version number bumped to reflect the 
change.

I've replied to this thread once before about how FreeBSD does things;

Idar Tollefsen wrote:
 >> As for manpower; it falls on the package maintainer to make sure versions
 >> are bumped were needed. I.e. not really more manpower, but probably more
 >> work and testing for maintainers.

Geet Hendrickx wrote:
 > No.  In pkgsrc, maintainers assume that users will use make update (or
 > pkg_chk or whatever) properly, as documented.  This implies rebuilding the
 > dependant packages anyway.  So no hacks.

Geet mentioned an example from FreeBSD; the update of gettext. When gettext was 
updated, every port that depended on it had it's version bumped. portupgrade -a 
therefore picked up gettext and all ports depending on it, figured out the build 
order, updated gettext and then updated all ports depending on it. If the 
gettext update failed, all the others would also fail with a message about a 
dependency failing it's build.

Of course, the problem is what happens if gettext gets updated, but a port that 
depends on it fails? This is, if I've understood things correctly, the reason 
why pkgsrc rips out packages depending on the one being updated before updating it.

The difference between FreeBSD's ports and pkgsrc here, as I see it, is pkgsrc' 
expectation of failure. And rightly so.

It's very seldom that a FreeBSD port fails to build, and that's why portupgrade 
-a "just works". pkgsrc packages on the other hand frequently fails. I suppose 
that has to do with the number of platforms pkgsrc is trying to support (I'm not 
using it on NetBSD, things might be better there), the available manpower, or 
any combination of such things.

For instance, I've reported 13 bugs and problems to GNATS since I started using 
pkgsrc in April, all of them with patches for suggested fixes. Some where for OS 
X, some were for Solaris. I've gotten feedback on one of them, eight are not 
assigned yet and none of them have been closed. In comparison, I've only ever 
reported 3 problems to ports' GNATS, whereof one was an update request, in the 
five years I've used it.

At this rate, no wonder builds fail. Until the quality improves, I would have to 
agree that the portupgrade -a approach wouldn't "just work" for pkgsrc and that 
rebuilding everything is indeed the only way to do it.

That doesn't mean that there aren't room for improvements. I would think 
backups, as this thread has mentioned several times, so that old packages can be 
restored and the system remain healthy even if a build fails is a no-brainer. 
Better algorithms for pkg_chk and the likes so that a package only gets rebuilt 
once even if more than one package that needs updating depends on it is another 
idea that has been discussed (and partially implemented?) on this list before.

> # pkgdb -F
> --->  Checking the package registry database
> [Updating the pkgdb <format:bdb1_btree> in /var/db/pkg ... - 659 packages found
> (-0 +2) .. done]
> Stale origin: 'textproc/dixit': perhaps moved or obsoleted.
> Stale dependency: kdeaddons-kate-plugins-3.4.0 -> libusb-0.1.7_1 (devel/libusb):
> libunicode-0.4_4 (score:22%) ? ([y]es/[n]o/[a]ll) [no]
> New dependency? (? to help):
> Skip this? ([y]es/[n]o/[a]ll) [yes]
> Skipped.
>   <long list deleted>
> 
> What does score 22% mean ?  It's not explained in the man page for pkgdb.

It's a 22% likelihood that this is the port you're looking for. The suggested 
port, in my experience, is almost always wrong, even when pkgdb gives it a high 
probability. "long list deleted" was a little exaturated tough, was it not? I've 
at most seen three of these on any one invocation of pkgdb -F. Then I again, I 
only have half your number of ports installed.



- IT