Am Montag, den 05.04.2010, 08:16 +0200 schrieb Maciej Mrozowski:
> On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote:
> 
> >>  Besides I 
> >> can already imagine PMS-related discussion regarding "make the PMs check 
> for rdeps per default before unmerging things" - thx but no thx.
> > This is not related to PMS. Paludis for example does it already with the
> > current EAPIs.
> So how does Paludis handle those issues?
> (Read my comments about "emerge" atomicy below)
> 
> > It is a problem which can _only_ be solved at the PM level. You have to
> > tell the PM when API breakages happen. Either by slotting the lib or by
> > something else.
> ^^^^^^^^^^^^^^^
> This is important - as slotting is not a practical solution. What is it then?
> 
> > Using guesswork to determine whether or not a library
> > should be removed may be a temporary solution. Remember: you're
> > partially ignoring a users request since he wanted the package to be
> > removed - and we all know how things like "protect the user from
> > himself" end up.
> 
> Unconditionally removing libraries (instead of preserving them) and making 
> their reverse runtime dependencies reinstalled is unacceptable because 
> "emerge" process involving multiple packages is not atomic. Simple as that.
A side mark: preserving libs may work in a number of cases, but there
are a lot of (possible) examples where the rdeps (and/or the preserved
libs) are nevertheless broken or become useless (think of: ui-files,
plugins, dlopen'ed libs, etc.).

Please forget your atomicity. It's a really nice idea (and I'd like to
see it too) but not possible now or in the near future.


> Is this what you suggest? Correct me if I'm wrong:
> 1. Users wants to uninstall or reinstall package, we let him do it provided 
> reverse runtime dependencies are satisfied afterwards. Let's say he wants to 
> upgrade expat.
> 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime 
> reverse deps will still be satisfied when we upgrade.
> 3. Expat has been upgraded sucessfully,
> 4a. "emerge" discovers reverse runtime dependencies are broken and it starts 
> to rebuild them, then it bails out due to error ld: libexpat.so.<sth> not 
> found. Because step 3 cannot be rolled back (no atomicy) - game over.
> or
In that case you most probably have a problem in your dep-tree (either
unspecified deps or a dep-resolver bug)

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30