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?
Description: PGP signature