Re: [gentoo-dev] Proposal: ban mirror://gentoo/ from ebuilds

[Anthony G. Basile]

On 08/18/2011 05:15 AM, Thomas Sachau wrote:
> Diego Elio Pettenò schrieb:
>> Hello everybody,
>>
>> I have already said this before, but it looks like nobody cared. We have
>> a problem for what concerns Gentoo-generated distfiles.
>>
>> This includes custom snapshots, custom packages, patches, patchsets, and
>> so on so forth. While it was infra that (back when I joined at least)
>> asked not to use dev.gentoo.org for hosting said fails and rather prefer
>> to use mirror://gentoo/, they already stated that it's not a problem to
>> do so until we have a proper system in place (system that has been
>> considered and worked on for quite a bit already and yet is not
>> available).
>>
>> Unfortunately, as long as the mirror://gentoo/ option is still
>> maintained, we'll end up with situations like today's gnuconfig that
>> couldn't be fetched, causing all ~arch users to see the same failure,
>> because the distfile wasn't uploaded to the staging area. Of course the
>> same could happen with a stable SRC_URI, but then it would fail after
>> hitting that, rather than going through half the gentoo mirrors trying
>> to find a file that is not there.
>>
>> So, anybody has reasons beside laziness, or concern for infra's disk
>> usage (that argument is allowed to come only from infra members!), to
>> not go this route?
>>
>
> I see no improvement from this proposal. If a tarball is not uploaded, the users will always fail to
> get it, independent from the place, where it should be going to. And even if you put the
> dev.gentoo.org address in SRC_URI, portage will first check the mirrors before it checks SRC_URI, so
> this would in the end result in even 1 more download try without success.
>
> The argument about dropped tarballs, once the ebuilds gets removed might weight a bit more, but you
> cannot depend on other upstream keeping their tarballs around forever, so i see no requirement for
> us preserving only specific tarballs (those created by our devs), while upstream tarballs could
> already be gone and are not preserved, once the ebuild for it is gone.
>

What alternative are you proposing to mirror://gentoo/ if upstream
doesn't provide a tarball, eg with large patchsets the maintainer
constructs?  Anticipating your answer might be "keep them in your dev
space", then what would be the deprecation policy for distfiles that are
no longer used by ebuilds?  If foresee a tension between keeping all the
distfiles vs disk space, although Patrick's point of cheap hardware is
well taken.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535