[ On Friday, November 12, 2004 at 12:18:49 (-0500), Douglas Wade Needham wrote: ]
> Subject: problems with packages (was Re: CVS commit: src/distrib/sets)
>
> I don't know if the flaw which is causing folks to go around
> pkg_delete and use rm is with the pkgsrc system or the procedures
> people use, or both.

Pkgsrc is indeed far from perfect (but it is reflecting only that the
3rd-party add-on software managed by pkgsrc is _extremely_ far from
perfect when it comes to managing it in a production environment).

However that doesn't really have anything to do with why I (or perhaps
even others) like to "rm -rf /usr/pkg" and start from scratch.

Even if "pkg_delete *" left nothing behind but locally modified copies
of system-specific configuration files (and maybe locally generated,
system-specific, data files), I'd still want to use the quick-and-dirty
"rm -rf" or "newfs" trick simply because it is faster and easier.

"pkg_delete \*" should work and it shouldn't leave anything behind that
shouldn't be there afterwards, and like I said I'd be more than happy to
go back to using it if I could totally blur or ignore any and all lines
between 3rd-party add-on packages and the base system packages.

(I don't want RPM hell with many versions of libc, but I would like to
be able to replace or upgrade named or ntpd or even /bin/sh without
having to have re-built a whole custom OS release just to get a new
syspkg with what I want in it)

> 1) Fix the issues with 'make update'.  Like Laurent and others who
>    have stated they have been bitten by this, I too have been bitten,
>    and is one reason why I resurrected my system for doing builds in
>    chrooted sandboxes.

Well I don't think that's anywhere near priority #1.  Anyone who's not a
developer (of sorts, e.g. anyone not tracking the bleeding edge) should
be using pkgsrc in the way it was intended, and _not_ trying to do a
"cvs update && make update".  You allude to the same thing, and for much
the same reasons, in another part of your message.

Building in Chrooted sandboxes is only a half-baked solution too -- but
I prefer a wholly separate system on which I can build binary packages
without having to worry about the time it takes or what doesn't work
while it's being rebuilt.  Nuke the world and start fresh and you'll
know your result is consistent and properly integrated.

Production system upgrades should always be done with binary packages,
and it is no big deal to have to delete all the packages being upgraded
before re-installing their new releases from new binary packages.
That's what maintenance windows are for.  If anyone really needs true
24x7 uptime then they've already got lots of other concerns that'll
drive them to having redundant systems that can be independently taken
offline and upgraded anyway.

> 3) Give some thought/consideration to sub-packages.  It would be nice
>    to have this added level, so that we do not end up with packages
>    such as foo, foo-man, foo-lib, foo-clients, foo-server, foo-opt1,
>    foo-opt2, and so on.

Oh, please, NO.  We have way _way_ too much of this insanity already.
The only time such division and splitting is necessary is when the
"opt1" and "opt2" and so on things actually conflict with each other in
the filesystem namespace.

When a package is built and installed it should come with all it's bits
and pieces and parts all in one lump.  It's rediculous to split
everything up unnecessarily and it causes enormous headaches and
overhead for pkgsrc maintainers and it leads to many unnecessary
mistakes and bugs.  Developers might not admit it or even realize it
consiously but the evidence is already stacking up in GNATS.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>