tech-pkg archive

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

Re: make replace

Joerg Sonnenberger <> writes:

> On Wed, Jul 07, 2010 at 08:50:39AM +0000, Jens Rehsack wrote:

>> Instead of arguing 'make replace' and pkg_rr should be discarded, I
>> prefer argues how we can improve the toolchain to support such things,
>> Why? Because I know about the issues and want to use 'make replace'
>> and pkg_rr anyway.
> I never said that "make replace" and pkg_rr should be discarded. I am
> saying that the way they currently behave doesn't work for non-trivial
> updates and that the core assumption of pkg_rr is questionable.
> "Doctor, every time I try to drink coffee, my eye hurts." "Have you
> considered taking the spoon out?"

You're twisting the facts in your argument.  The proponents of make
replace/pkg-rr really say:

  When it finishes successfully, all packages are in a good state.

  Almost all intermediate states, even if technically inconsistent
  (unsafe_depends set) are actually ok.  (Except for big ABI changes, in
  which case there are issues until pkg-rr finishes - but those are
  relatively rare.)

  Very often pkg_rr finishes successfully (after fixing any packages
  which would not have built normally, of course).

  Using pkg_rr, for me, is easier/faster/safer/less brain time/less
  diskspace/whatever than alternatives.

  If you prefer bulk builds or make update, that's fine with me.  It's a
  strength of pkgsrc that we have multiple options for updating.

People who use it understand that once in a while there is some
restructing of a package (splitting foo into foo-lib and foo, for
example), and then one has to remove a bunch of things and build anew.
So "the core assumption" is "usually, replacing packages one at a time
works", and it's not questionable -- it's been demonstrated to be true
and has a user community.

The discussion is not about pkg_rr users saying "in the presence of
renames it doesn't work, so I want you to do X and Y which are hairy".
It's specifically

  make replace has longstanding semantics, and pkg_add -U didn't
  implement them, so we want a way to implement the proper semantics
  that is as clean as possible (in terms of not overriding any checks
  that don't have to be - there is in fact just one)

  make replace and pkg_rr succeed very often.  If there's a case where
  they can be made to succeed instead of fail, and there's no harm done,
  we should do that.

Attachment: pgpetDj8_Yrq9.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index