| 1 |
On Tuesday 27 December 2005 04:08, Brian Harring wrote: |
| 2 |
> So note the comment in the email you are responding to about locking |
| 3 |
> down the used dep/rdeps for an install. |
| 4 |
|
| 5 |
That would be a maintenance nightmare. Every time a new KDE versions comes out |
| 6 |
a new ebuild revision for every package depending on KDE would be needed to |
| 7 |
work with this particular KDE version. Just for the sake of having to match |
| 8 |
with insufficient slot dependencies. |
| 9 |
|
| 10 |
I'll give another example: |
| 11 |
|
| 12 |
Application X works with KDE 4.0 (which implies that it will work with all KDE |
| 13 |
4.x versions). Locking the dependency down to e.g. kde-base/kdelibs:4.0 |
| 14 |
implies adding another ebuild revision depending on kde-base/kdelibs:4.1, |
| 15 |
another one on kde-base/kdelibs:4.2. In short: Even having slot dependencies |
| 16 |
they won't be used, because =kde-base/kdelibs-4* is the dependency, which |
| 17 |
matches and no one will add hundreds of ebuilds just to follow the limiting |
| 18 |
scope Portage is providing via slot dependencies. |
| 19 |
|
| 20 |
Based on the packages we have now in Portage, that would mean ~300 additional |
| 21 |
new ebuild revisions as a side effect of every KDE version bump. Simply |
| 22 |
ridiculous. |
| 23 |
|
| 24 |
|
| 25 |
Carsten |
Archives