/usr/ports & portupgrade when only using packages

[Mel]

On Wednesday 05 September 2007 17:42:55 Michael C. Cambria wrote:
> I need to set up a system that can only use packages.   I've always used
> ports, so I'm not exactly sure if I'm doing things properly.
>
> Should I (do I need to) use portsnap to populate /usr/ports?  Unless I
> really need something that doesn't have a pkg available, I will not be
> using ports.
>
> I've always used portupgrade, and plan to do so, using -PP (only
> packages) for this setup.  My first question is should I?

It needs the ports tree to know which packages to *upgrade*. I know of no 
ports management system that is able to use only binary and no ports tree. If 
you need to save space, consider mounting /usr/ports via nfs.

Now, whether you should use portupgrade...I'm not very positive about it and 
currently writing my own tools to do just that. I found that portupgrade uses 
a lot of things it shouldn't need to when in -PP mode (most notably running 
make all-depends-list before installing a new port and unpacking the entire 
package just to read it's +CONTENTS file for dependencies).
With an ever growing ports tree and the recent Xorg split, adding ~200 new 
packages to the basic install, I find it to become very slow.

If you're going to be using packages you build yourself on a build machine, 
like I'm doing, you're even in for a bigger surprise, because they are built 
using the 'packages' target. This target creates plist, which then becomes 
the packages' +CONTENTS file, on many occasions different from what has been 
installed on your build machine.

You could manage with pkg_add/pkg_delete, but then:
1) *You* have to find out which packages are eligible for upgrading
2) Upgrading a package will mean delete the old version before installing the 
new one
3) *You* will have to backup libraries manually.

(Yes, I realize portupgrade does this)
-- 
Mel

People using reply to all on lists, must think I need 2 copies.