tech-pkg archive

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

Re: make replace

On 07/06/10 16:17, Joerg Sonnenberger wrote:
On Tue, Jul 06, 2010 at 09:43:11AM +0000, Jens Rehsack wrote:
On 07/06/10 00:20, Joerg Sonnenberger wrote:
The more important problem is that due to the hierachical namespace ELF
has, this can create very strange bugs that are not directly visible
>from the binaries. Consider libfoo, which links against libbar, and
re-exports a symbol that has changed in size or type in the last libbar
update. The program foobar links against libfoo, but not against libbar,
but uses this symbol. With the way pkg_rolling_replace works, foobar is
essentially broken until the time it is replaced. At the very least, the
code path that is using the symbol is.

'pkg_add -u' has the same behavior, except that the time frame of
the inconsistency is smaller. The only safe way to solve that issue
is using
a transactional file system:


"pkg_add -u" has the same issue, but it is not related to whether the
system is transactional or not. It is not really specific to either
tool, but the point I wanted to raise is that just because a program
starts doesn't mean it will work correctly. The above scenario is one of
the most problematic ones.

For those who use it without reading, but:
On 06/25/10 20:32, S.P.Zeidler wrote:
> Our users tend to be able to read just fine ...

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.

The other point is the failures when packages are split and the new
versions conflicts with the installed ones (often seen in tex-pkgs's
and sometimes gnome related). This issue is perfectly handled by
'pkg_add -u', and pkg_rr fails for this.

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.


Home | Main Index | Thread Index | Old Index