[HOW-TO] cvsup for ports -- Re: compact portsnap db

[Ian Smith]

On Sun, 6 Jan 2008, Aryeh M. Friedman wrote:

 > >  > > If you don't have cvsup installed, run this command: # pkg_add -r
 > >  > > cvsup-without-gui
 > >  >
 > >  > It is better to use all ports or all packages so either do:
 > >
 > > Why do you say that?  Do you know of unresolved issues regarding the
 > > interactions of port versus package installations?  Any references?
 > 
 > I am not currently aware of any conflicts but the fact that they have
 > historical been more frequent then inter-port or inter-package
 > conflicts leads to the conculsion... unlike either of the above they
 > are harder to troubleshoot

The only problems I've ever seen with installing packages is that at
times the package-building farm gets a bit behind, when you might need
to build a desired newly updated port from source, and that in some
cases a package built with default options may not be what you want. 
php5 is one example of the latter, as the default options do not include
mod_php5 which (I gather?) is why most people install php at all. 

And yes there are some ports that don't have packages for licencing etc
reasons, though I can't recall ever having to install one of those.

Not everyone has fast hardware and good bandwidth, so installing from
packages for really big ports - such as X, KDE or Gnome, j{dk,re}, OO
and such - is almost mandatory on smaller systems.  Release CDs install
at least the former three as packages of course, for obvious reasons,
and at least around release times, up to date packages can be expected.

I just think saying "it's better to use all ports or all packages" is
poor and maybe misleading advice, particularly expressed without 'IMHO',
as it implies problems that RE should know about - especially right now!

 > >  > cd /usr/ports/net/cvsup-without-gui
 > >  > make install clean
 > >  >
 > >  > or after doing the above do a pkg_delete -a (assuming that your
 > >  > working with a clean machine [no ports/packages instaleld except cvsup]
 > >
 > > Why wouldn't pkg_delete -a remove your just-installed cvsup-without-gui?
 > 
 > Sorry for not being clear I meant before the reinstall (besides make
 > install would fail if you hadn't done a pkg_delete -a)

Hmm ok - thought you might be suggesting that port installs don't update
the package database in /var/db/pkg just the same as pkg_add does.

 > >  > > For more info on the supfile, look at this file on your FreeBSD
 > >  > > machine: /usr/share/examples/cvsup/ports-supfile
 > >  > >
 > >  > > Preferring cvsup to portsnap is kinda like preferring vim over
 > >  > > emacs...  It's a holy war and the vi/cvsup side uses less disk
 > >  > > space.
 > >  >
 > >  > Actually it is not like that at all.. cvsup/csup is the officially
 > >  > preferred method and any other method is a short cut of some kind...
 > >
 > > Please provide a reference URL to 'official' support of this claim?
 > 
 > This is a case of actions by the developer community speaks louder
 > then words:
 > 
 > 1. Csup is in the base system thus obvious preferred to either cvsup
 > or portsnap

% which portsnap
/usr/sbin/portsnap

 > 2. C(v)sup is more universal
 > 3. The only way to maintain an official local repo is via cvsup

You're talking about updating sources, ports and CVS too.  We were just
talking about maintaining the ports tree.  I sense nothing 'official'. 

 > >  > many of them have very subtle issues that the typical end-user should
 > >  > not notice but should be aware of...
 > >
 > > Issues such as?  And what other alternatives to c*sup and portsnap exist
 > > for ports tree management?
 > 
 > I can think of several off the top my head:
 > 
 > 1. Ftp ports.tar.gz and unpack

Sure.  Plus make fetchindex or such.

 > 2. Maintain a local repo like I do

Clearly not a job for portsnap :)

 > 3. Use portupgrade in conjunction with the above
 > 
 > I was specifically refeering to the 3rd option when I said there where
 > subtle issues.   Speicfically the way "make install" (recursive) and
 > "portupgrade -a" calculate the build order can lead to some issues
 > (like compiling the default OPTIONS before asking the user to select
 > OPTIONS)

It seems that here you're confusing port maintenance and upgrading
tools (portupgrade, portmaster etc and/or make install) with a choice
between c*sup and portsnap for maintaining the ports _tree_ and INDEX,
which is precisely all that portsnap is designed to do, and does well.

Sorry if I sound a bit harsh, but there seems to have been a flurry of
deprecation approaching folklore re installing from packages recently,
and I can't see that it's based on anything much factual.  My last big
portupgrade on this 300MHz 5.5-STABLE system began with 'portupgrade
-anPP' which fetched the vast bulk of a hundred or so ports as packages,
saving me many hours - if not days - of building.  YM probably V.

cheers, Ian