On Wed, May 23, 2001 at 07:38:52PM -0500, Frederick Bruckman wrote:
> On Wed, 23 May 2001, John Franklin wrote:
> > On Wed, May 23, 2001 at 06:13:54PM -0500, Frederick Bruckman wrote:
> > > Overwriting the base system files is nasty, because it makes your
> > > configuration really hard to reproduce after a system upgrade. (Been
> > > there!)
> >
> > Well, why doesn't pkgsrc check for a config file, then?  It should be
> > pretty trivial to patch the install to copy examples to something
> > like /usr/share/examples/{progname} and/or install a default config
> > file only if the config file doesn't already exist.
> 
> So what happens when sysinstall untars base.tgz? Or you do a "make
> build" in /usr/src?

Sysinstall runs only when you first install the system, or when you're
upgrading to a baseline, say 1.5.1.  It would do what you would expect,
which is overwrite the binaries that were updated with the pkgsrc patch.

The same is true of make build.  Yes, this might mean that the binaries
on disk may differ from those listed in the pkgsrc db.  Sysinstall could
be smart enough to correct the DB.  For that matter, so could make
build, but I really don't think that's the issue.

> The issue is not that pkgsrc doesn't support overwriting the base
> system files (which it doesn't), the issue is that the base build
> doesn't respect alien files in the base system. That's what /usr/local
> and /usr/pkg are for!

I'm sorry, but I don't see how the base build (/usr/src makefiles or
sysinstall) cares what's present.  They'll overwrite it with the
version you're installing.  I also don't see why pkgsrc couldn't be
adapted to support overwriting the base files.  In fact, ISTR someone
trying to pkg'ize all the base files.  (Thank you, whoever you are!)

> > This is, I think, what David is trying to get at, and something I'd
> > like to see the pkg collection address as well: updating the existing
> > system.  The NetBSD community prides itself in putting out the most
> > stable, most portable software quite possible in the world.  We pay
> > a price to do so: long delays between releases.  Typically, we've
> > seen a patch release every six months, and a minor number bump
> > every 18 months.  A lot can happen in that time.
> >
> > Since putting out 1.5, we've seen Security Alerts for ntp, ssh, bind,
> > ftpd, and libkrb.  Why can't we install the security patches through
> > pkgsrc?  I envision something like:
> >
> > foo# cd /usr/src/pkgsrc/SA
> > foo# cvs update [-r netbsd-1-x]
> > foo# make install
> > foo# [restart affected services, if make install can't]
> 
> Uh, if you can use cvs, why aren't you tracking the release branch?

If you're confused by the /usr/src/pkgsrc instead of /usr/pkgsrc, my 
apologies.  I keep a /usr/src partition on my systems and include
pkgsrc as one of the directories on it.

In answer to your question, I'm not tracking the release branch for
two primary reasons:

1. I don't want to dedicate the amount of drive space needed to keep
the entire source tree online on a production box.

2. Between 1.5.0 and 1.5.1 we go though 1.5.1ALPHA and 1.5.1BETA,
neither of which I want to upgrade to, certainly not on a daily or
weekly basis.  If I'm on a slower box, I don't want to spend upwards
of a week rebuilding everything.  If I'm on a production box, I
don't want to add to it's workload by rebuilding the entire system.
Sure, I could rebuild parts of the system, but I might miss something
whereas pkgsrc would Do The Right Thing.

> That -- the release branch -- is the carefully planned and integrated
> NetBSD that we know and love. Did you read those SA's? Every one of
> them explained that the latest fix's are in current and on the release
> branches, and a few even described how to replace your system binaries
> with pkgsrc versions, with appropriate caveats.

Yes, I did.  Yes, they do.  And I want it to be easier to do what could
be a very simple thing.  I don't want caveats, I don't want to install
versions in /usr/local or /usr/pkg and then move things about manually,
and I don't want to spend any more time than I have to addressing
the security alert, especially if I have [ several | dozens | hundreds ]
of machines to update.

If it comes down to "use NetBSD and manually do what pkgsrc could" or
"use Red Hat and trivially update via the RPMs", which do you think
I'll choose?

> So when you see an SA that seems to apply to you, do this:
> 
> 	cd /usr/src
> 	cvs update -r netbsd-1-5
> 	make build

Not on a slower system, and not on a production system where I need
the cycles, drive space and drive time for production purposes.  
Certainly not if I can say "cd /usr/pkgsrc/SA/foo && make install" 
or "pkg_add http://netbsd.org/SA/<arch>/foo" to update only the 
part I'm concerned about, quickly, easily, and with some measure
of confidence that I didn't overlook something.

> We _could_ distribute weekly numbered patch kits, and we _could_
> provide a java applet so that your browser could install them for you,
> but we don't! "cvs" makes all that crap obsolete and inferior. Even
> "sup" tracks the release as well as it tracks pkgsrc.

We could do all that, and gosh it would make my life easier.  I could
all but then train end users to do it.  (I'd have to give them root
access, which I'm not about to do.)

I wholly advocate using cvs or sup to track it... through the pkgsrc
system.

NetBSD is a powerful system.  Don't hamstring it by making it difficult
to keep it current and secure.  Pkgsrc consumes far less space than the
entire source tree, it would take less time to rebuild a package than
the system, and if network-based binary packages are used, it would be 
zero drive space, minimal time and high confidence.

jf
-- 
John Franklin
franklin@elfie.org
ICBM: N37 12'54", W80 27'14" Z+2100'