[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: make replace
On Wed, Jul 07, 2010 at 08:50:39AM +0000, Jens Rehsack wrote:
> I want to separate between two points of view (and remove one of them).
> You're talking about a fundamental issue in 'make replace' and pkg_rr,
> because it leaves a number of packages in a state which may not work
> (I do not repeat your examples here ...). This is right, but any update
> has this fundamental issue - so I don't want to dig deeper into that,
> except we're talking about transactional file systems.
I disagree. It is non-trivial to get right, but it can be done. The
problem with the reasoning about pkg_rr and by extension "make replace"
is that is at least one person constantly repeats the mantra of "it
works perfectly fine" and "all issues will fix themselve". Digging deeper
is pointless as long as it is not accepted that there are issues that
pkg_rr doesn't fix automatically and that the update procedure should be
fully automated modulo non-building packages. This doesn't have anything
to do with transactional file systems. They just make it easier to
rollback in case of a non-acceptable unhandable error.
> 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?"
Main Index |
Thread Index |