| 1 |
On Sat, Feb 2, 2013 at 6:44 AM, Vaeth <vaeth@××××××××××××××××××××××××.de> wrote: |
| 2 |
> I just ask that Gentoo should not *hinder* the user in installing/ |
| 3 |
> maintaining a package later by removing the tarballs (and possibly |
| 4 |
> patches) which once were available. |
| 5 |
|
| 6 |
So, I can see the validity of this argument insofar as it applies to |
| 7 |
Gentoo-generated tarballs and such, like patchsets. These tend to be |
| 8 |
hosted on dev webpages and such, and as a result they don't get any |
| 9 |
kind of version control like files in cvs do. |
| 10 |
|
| 11 |
Code that Gentoo creates should in general be revision-controlled. |
| 12 |
|
| 13 |
Another class of code is distfile tarballs that we create. Some |
| 14 |
packages have these because upstream does not have reliable source |
| 15 |
tarball hosting. Maybe they only host binaries and an scm that does |
| 16 |
not generate tarballs on demand. So, sometimes devs have to create |
| 17 |
source tarballs and host them somewhere, and these also do not get |
| 18 |
revision-controlled. I'm a bit torn on these because they are in fact |
| 19 |
large files and they're only marginally Gentoo-created, but they |
| 20 |
probably could never be recreated with a matching hash. If for |
| 21 |
whatever reason space was no object and we did revision-control these |
| 22 |
files we would need a mechanism to obliterate them entirely (or at |
| 23 |
least block access) should a licensing issue be discovered. Patches |
| 24 |
are something we could probably claim copyright or fair use over, but |
| 25 |
entire source tarballs clearly require a license to redistribute. |
| 26 |
|
| 27 |
I do have to agree with the earlier comment that Gentoo isn't a |
| 28 |
software archiving service. I think we SHOULD archive the stuff we |
| 29 |
create - if somebody wants to work on a better way of hosting patches |
| 30 |
this is something Gentoo should support (via infra/etc), but of course |
| 31 |
somebody has to step up and actually do that work, and it isn't |
| 32 |
reasonable to ask treecleaners/QA/etc to leave things with broken |
| 33 |
SRC_URIs in the tree until this is done. Broken SRC_URIs generate |
| 34 |
logspam and no doubt headaches in general for those who graciously |
| 35 |
maintain our mirrors. |
| 36 |
|
| 37 |
As far as upstream tarballs go - if somebody wants to archive them by |
| 38 |
all means do so, and patches for broken SRC_URIs that point to these |
| 39 |
patches should be consider welcome provided the package has no other |
| 40 |
serious flaws. However, maintaining an archive of tarballs for |
| 41 |
anything we EVER packaged sounds like a lot of work, and not a small |
| 42 |
amount of space/bandwidth/etc as well. Do we archive everything just |
| 43 |
in case? Do we periodically scan stuff in our attic in case a package |
| 44 |
we already removed has its sources disappear (and what do we even do |
| 45 |
then since we don't mirror removed pacakges)? Why bother trying to |
| 46 |
archive some distfiles if we don't archive all of them? This just |
| 47 |
sounds like a big mess, and not really our core mission. |
| 48 |
|
| 49 |
Rich |
Archives