tech-pkg archive

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

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

Joerg Sonnenberger <> 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

  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

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


  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

Home | Main Index | Thread Index | Old Index