tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/mk/flavor/pkg

On Sat, Jun 12, 2010 at 08:13:43PM -0400, Greg Troxel wrote:
 > (I would agree that on a production system with a professional sysadmin,
 > prebuilding packages is the right answer.  But on a personal machine
 > where short-term breakage only inconveniences the person doing the
 > update work, pkg_rr is a win.)

I'm not sure; I think that depends heavily on circumstances, what the
production machine does, and what happens if it breaks. E.g. on a
department mail server, a five minute downtime on a Saturday night to
rebuild and reinstall spamassassin isn't going to cause a problem; if
it fails partway through, you undo-replace.

Doing a full steam_roller during a scheduled downtime of a production
machine (especially, doing it blindly) is probably unwise, but that's
a different matter from doing a series of preplanned replaces.

oh, and btw, "make update" does have some bugs.

 > So, the incremental fix to (2) seems pretty clear:
 >   add a flag to pkg_add so that one can do "pkg_add -U" but override the
 >   check (turn it into a warning) that fails the update when there's a
 >   depending package with a dependency not satisfied by the new package.
 >   Essentially -f, but only for that check.   This could be either
 >      -U --no-strict-dependencies
 >   or it could be
 >      --replace
 >   which means the same thing.  And of course have make replace use it.
 > What do people think about that?

That makes far too much sense... :-)

David A. Holland

Home | Main Index | Thread Index | Old Index