Subject: Re: making 'make replace' safer
To: NetBSD pkgsrc Discussion <tech-pkg@NetBSD.org>
From: Greg A. Woods <woods@weird.com>
List: tech-pkg
Date: 07/17/2006 13:08:07
--pgp-sign-Multipart_Mon_Jul_17_13:08:04_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Mon, 17 Jul 2006 12:36:33 +0200,
Peter Schuller wrote:
>=20
> > > From a user perspective, I would often have no trouble taking the ext=
ra
> > > CPU usage hit if it meant decreasing the chances of trouble.
> >
> >   From a sysadmin perspective, it also means extra downtime for your
> >   service...
>=20
> Except taking the machine offline for an upgrade is not necessarily accep=
table=20
> to begin with. That is a problem that has to be solved in other ways IMO =
(and=20
> it looks like pkgsrc is approaching that).=20

That problem has actually been solved perfectly well from the very
beginning.

> Once there is a way to perform upgrades such that it does not affect the =

> running system (until everything is builtand the administrator hits the=20
> switch), that problem will go away. Then all that matters is that the upg=
rade=20
> *works* without having to manually debug packages.

Indeed and that's what binary packages allow.

One need only learn to build (_and_ TEST) binary packages on a
non-production machine and then use a regular, but very narrow window,
downtime period to upgrade the production machine.

I don't think it can be said too often in this or any other forum that
binary packages are THE _only_ way to go for production use.

Sure it's OK for Joe Developer to hoze his workstation for a while
(though he might not think so :-)), but anyone using packages in
production environments should be smart enough to have a spare build
machine (which in a pinch can also serve as a warm-swap machine for any
of the production servers too!).

Unfortunately the way Joe Developer's talk in this forum often seems to
give the impression to others (probably especially non-developers) that
there's some way to actualy upgrade packages on live systems.  That just
isn't so, and never was.  It may be possible some day, but that'll
probably still require chroot-ed builds and binary packages for final
production installs (or pkg-views installs, if you're so inclined).

"Oh, give me disk, lots of disk under speedy CPUs!
 Don't fence me in!
 Let me compile the wide-open source that I love.
 Don't fence me in!"

--=20
						Greg A. Woods

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

--pgp-sign-Multipart_Mon_Jul_17_13:08:04_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: fhQgM3S/XKCt3o1PVvlX4Mm07ibDTf+2

iQA/AwUBRLvD9mJ7XxTCWceFEQKPYgCdEa7VglC2jb4eToUE/K36lTcOjE0AoIpK
D3Yz9cmt/kEwh5hef9s7vcS3
=fuUP
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Jul_17_13:08:04_2006-1--