| 1 |
On Tuesday 27 December 2005 14:00, Jason Stubbs wrote: |
| 2 |
> If all three of those packages were first built against kdelibs:3.4 and |
| 3 |
> then kdelibs:3.5 became available then rebuilding any one of them without |
| 4 |
> rebuilding the others will break digikam. I can't see how it's directly |
| 5 |
> represented in the metadata unless you want to overload the meaning of |
| 6 |
> SLOT. |
| 7 |
|
| 8 |
It's not possible to represent that via dependencies. What is needed is some |
| 9 |
sort of introspection which relevant ebuild is built against which KDE |
| 10 |
version and if those _installed_ ebuild:kdever combinations match the one the |
| 11 |
_actual_ ebuild to emerge. |
| 12 |
|
| 13 |
But you're right about the overloading of the meaning of slots, because that's |
| 14 |
happening right now. Slots are used to install several versions of a package |
| 15 |
side by side. The idea Ciaranm and Brian are proposing to lock ebuilds |
| 16 |
depending on slotted packages down to a single slot is the redefinition. And |
| 17 |
once again: This doesn't match reality. |
| 18 |
|
| 19 |
|
| 20 |
Carsten |
Archives