1 |
Am Montag, den 05.04.2010, 08:16 +0200 schrieb Maciej Mrozowski: |
2 |
> On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote: |
3 |
> |
4 |
> >> Besides I |
5 |
> >> can already imagine PMS-related discussion regarding "make the PMs check |
6 |
> for rdeps per default before unmerging things" - thx but no thx. |
7 |
> > This is not related to PMS. Paludis for example does it already with the |
8 |
> > current EAPIs. |
9 |
> So how does Paludis handle those issues? |
10 |
> (Read my comments about "emerge" atomicy below) |
11 |
> |
12 |
> > It is a problem which can _only_ be solved at the PM level. You have to |
13 |
> > tell the PM when API breakages happen. Either by slotting the lib or by |
14 |
> > something else. |
15 |
> ^^^^^^^^^^^^^^^ |
16 |
> This is important - as slotting is not a practical solution. What is it then? |
17 |
> |
18 |
> > Using guesswork to determine whether or not a library |
19 |
> > should be removed may be a temporary solution. Remember: you're |
20 |
> > partially ignoring a users request since he wanted the package to be |
21 |
> > removed - and we all know how things like "protect the user from |
22 |
> > himself" end up. |
23 |
> |
24 |
> Unconditionally removing libraries (instead of preserving them) and making |
25 |
> their reverse runtime dependencies reinstalled is unacceptable because |
26 |
> "emerge" process involving multiple packages is not atomic. Simple as that. |
27 |
A side mark: preserving libs may work in a number of cases, but there |
28 |
are a lot of (possible) examples where the rdeps (and/or the preserved |
29 |
libs) are nevertheless broken or become useless (think of: ui-files, |
30 |
plugins, dlopen'ed libs, etc.). |
31 |
|
32 |
Please forget your atomicity. It's a really nice idea (and I'd like to |
33 |
see it too) but not possible now or in the near future. |
34 |
|
35 |
|
36 |
> Is this what you suggest? Correct me if I'm wrong: |
37 |
> 1. Users wants to uninstall or reinstall package, we let him do it provided |
38 |
> reverse runtime dependencies are satisfied afterwards. Let's say he wants to |
39 |
> upgrade expat. |
40 |
> 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime |
41 |
> reverse deps will still be satisfied when we upgrade. |
42 |
> 3. Expat has been upgraded sucessfully, |
43 |
> 4a. "emerge" discovers reverse runtime dependencies are broken and it starts |
44 |
> to rebuild them, then it bails out due to error ld: libexpat.so.<sth> not |
45 |
> found. Because step 3 cannot be rolled back (no atomicy) - game over. |
46 |
> or |
47 |
In that case you most probably have a problem in your dep-tree (either |
48 |
unspecified deps or a dep-resolver bug) |
49 |
|
50 |
-- |
51 |
Tiziano Müller |
52 |
Gentoo Linux Developer |
53 |
Areas of responsibility: |
54 |
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor |
55 |
E-Mail : dev-zero@g.o |
56 |
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 |