| 1 |
On Fri, 17 Jan 2014 18:28:41 +0000 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
|
| 4 |
> On Fri, 17 Jan 2014 17:47:58 +0100 |
| 5 |
> Tom Wijsman <TomWij@g.o> wrote: |
| 6 |
> > Maybe we can let the package managers only perceive it as keyworded |
| 7 |
> > or stable if all of its dependencies are keyworded or stable on the |
| 8 |
> > architecture that the user runs. Then we can have repoman just |
| 9 |
> > ignore checking dependencies' keywords when we keyword or stabilize |
| 10 |
> > them. |
| 11 |
> > |
| 12 |
> > Not sure how implementable this idea is though... |
| 13 |
> |
| 14 |
> It's going to hurt for four reasons that I can think of right now. |
| 15 |
> |
| 16 |
> Firstly, things you think are "obviously portable" sometimes aren't. |
| 17 |
|
| 18 |
We could write a search for architecture dependent / specific code. |
| 19 |
|
| 20 |
> Secondly, users already get confused by "stable use masks". This is |
| 21 |
> going to be even worse: users aren't going to understand why a noarch |
| 22 |
> package isn't available for them. |
| 23 |
|
| 24 |
We can improve the output of the package manager to make this easier |
| 25 |
to understand; one way is to clarify it, the other way is to just |
| 26 |
replace it by the actual archictecture the user runs. |
| 27 |
|
| 28 |
As a side note, I think we might want to name this anyarch... :) |
| 29 |
|
| 30 |
> Thirdly, you have to decide how to deal with long chains and cycles in |
| 31 |
> noarch dependencies. |
| 32 |
> |
| 33 |
> Fourthly, the interaction with || deps is an awful mess. |
| 34 |
|
| 35 |
Yes, these are though problems to resolve; my mind came up with that |
| 36 |
this idea needs recursion, hence the "not sure how implementable". |
| 37 |
|
| 38 |
A cycle can be broken by stopping to continue to a certain dependency |
| 39 |
if that dependency is of the parent reverse dependencies, capture the |
| 40 |
set of packages as a cycle. Then check for each package in the cycle if |
| 41 |
their dependencies satisfy each package; if so, all the packages in |
| 42 |
the cycle are satisfied. |
| 43 |
|
| 44 |
Of course, this doesn't take into account more complex cycles were two |
| 45 |
cycles are connected to each other; but if we would have such thing, |
| 46 |
I'd rather see that get fixed in the Portage tree as that sounds like a |
| 47 |
needlessly complex set of ebuilds. |
| 48 |
|
| 49 |
Long chains might or might exist and might or might not be problematic, |
| 50 |
that's something we would need to test out when this is implemented. |
| 51 |
|
| 52 |
|| deps can be done, just check them in the same order like before; |
| 53 |
what I'm more scared of is the amount of anyarch/noarch there would be |
| 54 |
added to the Portage tree, just a few can be easily done. |
| 55 |
|
| 56 |
If it is going to be a large share of the Portage tree we'll want to |
| 57 |
look for another design or just not change how this works at all. |
| 58 |
|
| 59 |
-- |
| 60 |
With kind regards, |
| 61 |
|
| 62 |
Tom Wijsman (TomWij) |
| 63 |
Gentoo Developer |
| 64 |
|
| 65 |
E-mail address : TomWij@g.o |
| 66 |
GPG Public Key : 6D34E57D |
| 67 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives