| 1 |
On Thu, 2020-03-19 at 12:17 -0500, Gordon Pettey wrote: |
| 2 |
> On Thu, Mar 19, 2020 at 9:47 AM Alec Warner <antarus@g.o> wrote: |
| 3 |
> |
| 4 |
> > On Thu, Mar 19, 2020 at 6:52 AM Gerion Entrup <gerion.entrup@×××××.de> |
| 5 |
> > wrote: |
| 6 |
> > |
| 7 |
> > > Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric: |
| 8 |
> > > > On Wed, 18 Mar 2020 17:52:25 +0000 |
| 9 |
> > > > James Le Cuirot <chewi@g.o> wrote: |
| 10 |
> > > > |
| 11 |
> > > > > Not quite. Tools like repoman will need to be updated to understand |
| 12 |
> > > > > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with |
| 13 |
> > > > > only KEYWORDS="noarch". I do think the idea has merit though. |
| 14 |
> > > > |
| 15 |
> > > > But the inverse is _not_ true, an ebuild with KEYWORDS="noarch" |
| 16 |
> > > > *cannot* depend on another ebuild with only KEYWORDS="amd64". |
| 17 |
> > > Maybe I misunderstand something but shouldn't that be the normal case? |
| 18 |
> > > Every single Python package (candidates for noarch) for example depends |
| 19 |
> > > on the Python interpreter, which must have non noarch keywords. |
| 20 |
> > > |
| 21 |
> > > |
| 22 |
> > > > Otherwise it breaks the entire stabilization graph. |
| 23 |
> > > The condition would be: If the interpreter is stable for an arch, all |
| 24 |
> > > it's interpreted code is also stable for this arch. |
| 25 |
> > > |
| 26 |
> > |
| 27 |
> > Much of the concern is that this condition is not true for all interpreted |
| 28 |
> > code. |
| 29 |
> > |
| 30 |
> > -A |
| 31 |
> > |
| 32 |
> > |
| 33 |
> > > |
| 34 |
> > > Best, |
| 35 |
> > > Gerion |
| 36 |
> > > |
| 37 |
> If noarch is an alias that includes all keywords, KEYWORDS="noarch -sparc" |
| 38 |
> works (in Portage, not sure what PMS says about keyword additivity) and |
| 39 |
> doesn't break your keyword dependency graph for a Python package that for |
| 40 |
> whatever reason doesn't function on sparc. |
| 41 |
> |
| 42 |
> Semantically, noarch says it hasn't been tested on any arch, so Kent's |
| 43 |
> evidence follows. Once you get a negative test result from an arch, you add |
| 44 |
> -arch to that package. It's not called "allarches". |
| 45 |
|
| 46 |
So what happens when you try to emerge noarch package that has -sparc |
| 47 |
dependency on sparc? Right now, the package manager is able to |
| 48 |
immediately tell you it's wrong. With noarch, for every package you |
| 49 |
have to traverse the whole dependency graph to make sure. |
| 50 |
|
| 51 |
Read: things will become much slower. It's not like they're fast |
| 52 |
anyway. |
| 53 |
|
| 54 |
-- |
| 55 |
Best regards, |
| 56 |
Michał Górny |
Archives