tech-pkg archive

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

Re: make replace

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

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.


Home | Main Index | Thread Index | Old Index