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, andre-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: BEGIN TRANSACTION DO UPDATE COMMIT"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. Jens