| 1 |
On Tue, 2019-10-29 at 13:23 +0100, Ulrich Mueller wrote: |
| 2 |
> > > > > > On Tue, 29 Oct 2019, Michał Górny wrote: |
| 3 |
> > Dnia October 29, 2019 9:34:01 AM UTC, Fabian Groffen <grobian@g.o> napisał(a): |
| 4 |
> > > /space/distfiles-local is no longer copied to the mirrors? or just |
| 5 |
> > > not copied in the subdir-hierarchy? |
| 6 |
> > The latter. |
| 7 |
> |
| 8 |
> So, what has to be be done to have it appear in the proper place? Should |
| 9 |
> the file be placed in a subdir of /space/distfiles-local/? That seems to |
| 10 |
> be error prone, and certainly could be automated? |
| 11 |
|
| 12 |
The file should be placed in SRC_URI, and emirrordist will take care of |
| 13 |
fetching it. |
| 14 |
|
| 15 |
> |
| 16 |
> > > Just wondering. Do you mean it isn't valid that some upstreams do |
| 17 |
> > > this (yes horror)? We surely need a way to work around that ... |
| 18 |
> > I mean the method using same filename and expecting distfiles-local to |
| 19 |
> > overwrite it. It is preferable to just rename it. |
| 20 |
> |
| 21 |
> Looks like this will break backwards compatibility. IIUC, backwards |
| 22 |
> compatibility is also broken on the receiving side, that is, |
| 23 |
> mirror://gentoo/ in SRC_URI will no longer work as expected? |
| 24 |
|
| 25 |
Yes, this was noted in the top mail. |
| 26 |
|
| 27 |
> Shouldn't GLEP 75 have mentioned this? It's certainly something that |
| 28 |
> needs to be discussed before the GLEP is implemented. |
| 29 |
|
| 30 |
GLEP only covers how regular distfile fetching works. Third-party |
| 31 |
mirrors are out of scope, and all the people working on it and reviewing |
| 32 |
it have missed the problem. That said, this can't be fixed within |
| 33 |
bounds defined by PMS. |
| 34 |
|
| 35 |
Given that mirror://gentoo is discouraged since at least 2011, I don't |
| 36 |
see a big deal here. One day it'll stop working; we should stop using |
| 37 |
it before then. |
| 38 |
|
| 39 |
-- |
| 40 |
Best regards, |
| 41 |
Michał Górny |
Archives