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-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
smime.p7s
Description: S/MIME cryptographic signature
