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.
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
4b. "emerge does not discover those and does nothing. python is broken so 
emerge cannot be used anymore. Game over

-- 
regards
MM