| 1 |
On Wed, Jun 13, 2007 at 04:35:31PM +0200, Robert Buchholz wrote: |
| 2 |
> The problem is rather that the patches are gone from the distfiles |
| 3 |
> mirror after two weeks. The sources often stay upstream, but could |
| 4 |
> also be gone. |
| 5 |
> |
| 6 |
> Is there an archive for these files I missed? |
| 7 |
|
| 8 |
That archive ('purgatory' being the name used for it) isn't publically |
| 9 |
accessible; had suggested it in the past, but infra folks didn't |
| 10 |
think it would be needed. |
| 11 |
|
| 12 |
Few issues if it were opened up; |
| 13 |
|
| 14 |
1) it's not a true vcs, just a directory. Meaning |
| 15 |
|
| 16 |
1.a) it's collapsing down the trees history of distfile names; if |
| 17 |
ebuild x refs 'patch', gets removed, 'patch' goes into purgatory. If |
| 18 |
ebuild y refs 'patch', which is a different file, then gets removed, |
| 19 |
ebuild ys' version of 'patch' is whats is now in purgatory (last used |
| 20 |
basically). |
| 21 |
|
| 22 |
1.b) skimped a bit in the description above; 'patch' gets removed from |
| 23 |
purgatory when ebuild 'y' is added to the tree- the chksums will |
| 24 |
differ, thus it throws out the copy that no longer is relevant to it's |
| 25 |
job (maintaining the mirror image). |
| 26 |
|
| 27 |
|
| 28 |
2) if implemented, likely to be a single box- meaning stuff shouldn't |
| 29 |
rely on it as an upstream URI, they should mirror it themselves. |
| 30 |
|
| 31 |
3) mirror maintenance, if an ebuild is added to the tree that uses |
| 32 |
that specific distfile name, as hinted at in 1.b, the file is removed |
| 33 |
from purgatory- this *includes* if the chksums match. Basically, if |
| 34 |
the file is needed on the mirror image, it copies it over and wipes |
| 35 |
the purgatory copy of it (intention is to keep space usage down). |
| 36 |
This obviously would break any ebuilds daftly ignoring #2, and using |
| 37 |
the purgatory host as an upstream URI. |
| 38 |
|
| 39 |
|
| 40 |
Personally, I think at least for devs, having access to purgatory |
| 41 |
would be a good thing. Folks seem to have learned over the last few |
| 42 |
years, but dealt with a lot of requests where a dev screwed up and |
| 43 |
needed to pull a file out of purgatory. Perhaps they've gotten wiser |
| 44 |
since, dunno. Either way, if trying to pull a file out of |
| 45 |
purgatory, bug your friendly infra monkey, or zmedico if you need a |
| 46 |
specific file out- they ought to have access. |
| 47 |
|
| 48 |
For effectively random anonymous, http/ftp, not sure about |
| 49 |
that. Think some form of access is needed, don't think it should |
| 50 |
really be usable as an upstream host. |
| 51 |
|
| 52 |
~harring |
Archives