Re: make replace

[Jens Rehsack <rehsack%googlemail.com@localhost>]

On 07/07/10 14:49, Joerg Sonnenberger wrote:
> 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.

Not really. While doing an update with 'pkg_add -u', starting an
application will fail the same way like starting the application
while pkg_rr runs. I do not know a way to update all dependent
packages at once (having the obligatory install-script in mind, e.g.
for tex-packages).

> 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".

It works perfectly fine - until you hit some of the natural limitations
of 'make replace'. Those limitations are known and there is a known
way how to resolve them. I agree, that some more features could be
helpful for pkg_rr - but conflicts during split of packages can not
be handled by 'make replace', there must be additional support in
external tools. I'm not sure if pkg_rr is the right place for that,
but this might discussed in another thread ...

> 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 is possible using 'pkg_rr -k', or do I miss something there?

> 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.

I understood your arguing of the "fundamental issue" exact for the
inconsistent state while running pkg_rr. ELF symbol export chains
belongs to that.

It seems that I did not understand what kind of other error you're
talking about.

> > 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.

In that case it would be great if you help out by phrasing the core
assumption better and probably pointing a way how to get it work for
non-trivial updates.

Describe use-cases and how do you think they should be handled. Not
to abstract - do it for real examples.

Jens