Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes:
> On Sat, Jun 12, 2010 at 09:29:50PM +0000, David Holland 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.
The difference is:
with make update, in the best case, packages will be missing during
compiling. In a typical case, out of 100 packages 2 will fail to
build and you'll be left in a broken state with far more than the 2
missing. This actually used to happen to me all the time, which is
why I asked Nick to write pkg_rr.
with make replace and pkg_rr (and destdir, which works very well with
tihs and I'm a fan of), each package will be missing for a few
seconds. In the best case, there will be no ABI incompatabilities and
all packages will build cleanly. In a typical case, there will
occasionally be some ABI incompatabilities, and a few packages will
fail to build. You'll be left with old versions of a few packages and
everything else rebuilt.
How bad is the lossage in the pkg_rr case? Lots of people are using it,
and they obviously think it's a better bet than going through the work
of building packages in a chroot, or of the problems that make update
runs into. (I'm not saying make update has bugs, but rather pkgsrc
packages only build 99% of the time, which is really amazingly high and
an achievement to be proud of.) I'm not claiming its perfect, just that
there are people and situations for which it's a reasonable choice.
>> 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.
So, if you think that the problems of make replace/pkg_rr are so serious
that they outweight the convenience, that's fine, and a reasonable
position. But there's no basis to say that replace/pkg_rr is so broken
that anyone who wants to use it is confused and should just be told not
to. After all, the tsorted rolling replace fixes all the broken
dependencies, so we're just arguing about the time frame of the breakage
(missing package or broken dependency) and the nature of it, and we're
evaluating the odds of various situations in terms of total harm vs
effort - not something with a black and white answer.
(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.)
So, if we step back from the current discussion, we can hopefully agree
on principles/goals:
the point of pkgsrc is to serve the needs of users. we have users
with differnt goals and constraints in terms of needed reliability,
available time, etc.
updating packages to newer versions of pkgsrc is basically hard
people who want to choose safety properties like "no package is ever
installed with a broken dependency, even if that means sometimes some
of my packages aere missing" should be able to do so. (This is make
update.)
people who want to choose liveness properties like "my packages remain
in place while I update them one at a time so that even if the update
has trouble in the middle almost all of them are there, even if that
means sometimes dependencies are broken" should be able to do so.
(This is make replace and pkg_rr.)
people who want to choose properties like "I need safe dependencies,
and minimal downtime, and I'm willing to spend the time to prebuild
all packages I want in a chroot and manage them with pkg_chk" can do
so. (This is pkg_comp or pbulk and pkg_chk
remove-mismatched/add/update.)
Are these agreeable to all? If not, please point out what's wrong - I'm
trying to be evenhanded.
Given the above, the big problems we have are:
1) shlib changes don't cause dependency failures (dependency "foo>=12"
is basically incorrect). We all agree this would be good to fix, I
think, and no one's done the work yet.
2) make replace fails due to pinned dependencies and/or the override
to make it work is overly broad
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?
Attachment:
pgpgRo2ZYs8Lt.pgp
Description: PGP signature