Joerg Sonnenberger <joerg%britannica.bec.de@localhost> 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