| 1 |
On Tuesday 30 June 2009 23:17:02 Massimiliano Ziccardi wrote: |
| 2 |
> >It's far preferable to let people like yourself suffer the consequences of |
| 3 |
> |
| 4 |
> not |
| 5 |
> |
| 6 |
> >reading documentation |
| 7 |
> |
| 8 |
> Touched :-) |
| 9 |
> |
| 10 |
> However, I read the documentation. |
| 11 |
> It's just that this is my first gentoo installation: I didn't get I had to |
| 12 |
> uninstall the older version of the software to upgrade to the new one. |
| 13 |
|
| 14 |
You get to learn those tricks as you go along. Normally, one just upgrades and |
| 15 |
portage takes care of the "install old one, install new one" step. But KDE |
| 16 |
split and monolithic ebuilds covering the same KDE package are different in |
| 17 |
this regard - they are incompatible and cannot co-exist on the same machine. |
| 18 |
|
| 19 |
> Especially when it says 'We still provide monolithic ebuilds for 3.5 (up |
| 20 |
> till 3.5.9) and they are ***cleanly interoperable*** with the split ones.' |
| 21 |
|
| 22 |
That's a strange statement for the document to make. Split and monolithic can |
| 23 |
interoperate as long as you keep them cleanly separated. Take an example - |
| 24 |
kdepim and kdegames. Both have full monolithic and split ebuilds. You might |
| 25 |
decide you do indeed want all of kdepim [1] but not all the games. So you |
| 26 |
could emerge kdepim and selectively pick the few split-ebuild games you do |
| 27 |
want. |
| 28 |
|
| 29 |
What you can't do is also try to emerge kmail - that clashes with the kmail |
| 30 |
that kdepim wants to put there. |
| 31 |
|
| 32 |
[1] Here you would actually use kdepim-meta in the real world (it pulls in all |
| 33 |
the kdepim split ebuilds), but this is a demonstration, not a list of accurate |
| 34 |
install instructions. |
| 35 |
|
| 36 |
> |
| 37 |
> However, I think now I understand how it works a little bit more (but not |
| 38 |
> too much ;-) ). |
| 39 |
> |
| 40 |
> One more thing: couldn't those 'stable users' read the documentation too, |
| 41 |
> and unmask the obsolete package (if they were masked)? |
| 42 |
|
| 43 |
Think about this. You are asking users who have been doing something one way |
| 44 |
for years, to all of a sudden have their packages masked, their systems |
| 45 |
broken, expect them to go and find documentation (the location of which is not |
| 46 |
easy to provide at that time), unmask stuff and continue. |
| 47 |
|
| 48 |
Why? And for what benefit? |
| 49 |
|
| 50 |
The way it is done is the best possible way for all the users. Existing users |
| 51 |
continue as they did, new users get to make a choice first (which is something |
| 52 |
they have to do anyway). |
| 53 |
|
| 54 |
> |
| 55 |
> Massimiliano |
| 56 |
|
| 57 |
-- |
| 58 |
alan dot mckinnon at gmail dot com |
Archives