| 1 |
Hi everyone |
| 2 |
|
| 3 |
I'd like to bring bug #229521 to your attention and see whether we can |
| 4 |
come up with a solution for it. |
| 5 |
|
| 6 |
The problem: |
| 7 |
A package "foo" depends on a slotted package "bar" _and_ more than one |
| 8 |
slot of "bar" can satisfy this dependency. |
| 9 |
|
| 10 |
Why this is a problem: |
| 11 |
If the dependency looks like one of the following: |
| 12 |
* DEPEND=">=cat/bar-2" |
| 13 |
* DEPEND="<=cat/bar-3" |
| 14 |
* DEPEND="|| ( cat/bar:2 cat/bar:3 ) |
| 15 |
then the package manager doesn't know after building "foo" which slot of |
| 16 |
"bar" has been used to build "foo". On the other hand might this |
| 17 |
information be needed to debug problems with package "foo". |
| 18 |
|
| 19 |
The problem gets even worse as soon as RDEPEND comes in: |
| 20 |
(assuming the same examples from above but with RDEPEND) |
| 21 |
* The package manager currently doesn't record which slot has been used |
| 22 |
and can't therefore track whether the user will destroy something in |
| 23 |
case he uninstalls one of the slots of "bar" |
| 24 |
* The package manager can't sanely consider whether an update for a slot |
| 25 |
is actually needed |
| 26 |
|
| 27 |
Furthermore it is possible that a package "foo" which used one slot of |
| 28 |
"bar" to build may also use a different slot on runtime (think of |
| 29 |
plugins for a slotted app). |
| 30 |
|
| 31 |
(list not necessarily conclusive) |
| 32 |
|
| 33 |
Since this has (again) enough potential to result in a flamewar, I'd |
| 34 |
like to point out what I think we should do/avoid: |
| 35 |
|
| 36 |
What I think we should do now: |
| 37 |
* Complete the list of problems/use cases |
| 38 |
* Sort the cases by importance |
| 39 |
* See that we can come up with a common solution to at least 60% of the |
| 40 |
cases (yes, we may also actively decide to _not_ support certain cases, |
| 41 |
but we have to be aware of them) |
| 42 |
* Decide when it should be implemented, what is needed to implement it |
| 43 |
and who's involved in that |
| 44 |
|
| 45 |
What I think we should not discuss (right now): |
| 46 |
* Which package manager has what implemented (remember: it's more |
| 47 |
interesting right now _why_ it has been decided to do it like that) |
| 48 |
* How "|| ( cat/bar:2 cat/bar:3 )" could be expressed in a simpler way. |
| 49 |
This is pure syntactic sugar |
| 50 |
* How the implementation should be done or what else it should include. |
| 51 |
We should concentrate on "what is needed that the package manager devs |
| 52 |
can implement it properly" |
| 53 |
|
| 54 |
Thanks in advance, |
| 55 |
Tiziano |
| 56 |
|
| 57 |
-- |
| 58 |
------------------------------------------------------- |
| 59 |
Tiziano Müller |
| 60 |
Gentoo Linux Developer |
| 61 |
Areas of responsibility: |
| 62 |
Samba, PostgreSQL, CPP, Python, sysadmin |
| 63 |
E-Mail : dev-zero@g.o |
| 64 |
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 |
Archives