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.
signature.asc
Description: OpenPGP digital signature
