[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 11:54:35PM +0200, Joerg Sonnenberger wrote:
> > My point, which you have ignored entirely, is that doing exactly this
> > during a scheduled downtime is currently the only remotely
> > sane/feasible way to update Perl. There is no way around this problem
> > without requiring extra pkgsrc installs and/or chroots.
> How is this different from what "make update" does other than that "make
> update" doesn't pretend that anything is usable in the mean time.
I can think of at least five issues off the top of my head:
(1) all the packages that depend on perl because there's a perl
script somewhere in their dependency graph (which is a lot of
fairly large packages) can be skipped, whereas "make update"
unconditionally erases them and recompiles them regardless;
(2) you can readily control the order in which dependent packages
are rebuilt, so as to minimize downtime for critical services
instead of e.g. rebuilding gimp before mysql;
(3) you can avoid recompiling the same packages repeatedly in the
presence of multiple updates of ancestor packages; e.g. if you
"make update" in perl, then jpeg, then python26, then libX11,
gimp and several other large things are pointlessly recompiled
(4) a package that is partly functional before being recompiled
remains partly functional, instead of being removed entirely;
(5) you don't trip on various bugs that occur with update; PRs
28812, 42002, and 42894 come to mind, along with the issue
where sometimes packages get deinstalled and recompiled a
second time in the same update run (which I don't think has a
All of these are sufficiently significant that while many people use
pkg-rr, I doubt anyone much uses "make update" exclusively.
> > Again, it seems to me that you are working towards a world where extra
> > pkgsrc installs and/or chroots are mandatory, and I think that this is
> > seriously misguided.
> If you care about keeping your systems running, anything else is
> misguided. I certainly don't want to start compiling any non-trivial
> package during a maintainance window.
If you "care about keeping your systems running" in the sense of never
doing anything that's temporarily unsafe, as appears to be the
criterion you have in mind, running software written in C is
misguided. If you look really hard you might still be able to find a
The rest of us would appreciate it if you didn't gratuitously break
David A. Holland
Main Index |
Thread Index |