I am look in the code, i have found this one: SRC_URI="mirror://sourceforge/e2fsprogs/${PN}-${UP_PV}.tar.gz https://498412.bugs.gentoo.org/attachment.cgi?id=368058 -> ${PN}-1.42.9-mint-r1.patch" Patch straight from bugzilla attachment? Huh? Should be moved at devspace at least.
(In reply to Mikle Kolyada from comment #0) > I am look in the code, i have found this one: > > SRC_URI="mirror://sourceforge/e2fsprogs/${PN}-${UP_PV}.tar.gz > https://498412.bugs.gentoo.org/attachment.cgi?id=368058 -> > ${PN}-1.42.9-mint-r1.patch" > > Patch straight from bugzilla attachment? Huh? Why? Does it fail to download? The package is not with RESTRICT=mirror > > Should be moved at devspace at least. ...
(In reply to Samuli Suominen from comment #1) > (In reply to Mikle Kolyada from comment #0) > > I am look in the code, i have found this one: > > > > SRC_URI="mirror://sourceforge/e2fsprogs/${PN}-${UP_PV}.tar.gz > > https://498412.bugs.gentoo.org/attachment.cgi?id=368058 -> > > ${PN}-1.42.9-mint-r1.patch" > > > > Patch straight from bugzilla attachment? Huh? > > Why? Does it fail to download? The package is not with RESTRICT=mirror > > > > > Should be moved at devspace at least. > > ... Change the header. Another question why we should keep it in bugzilla attachment but not in filesdir for example?
(In reply to Mikle Kolyada from comment #2) > (In reply to Samuli Suominen from comment #1) > > (In reply to Mikle Kolyada from comment #0) > > > I am look in the code, i have found this one: > > > > > > SRC_URI="mirror://sourceforge/e2fsprogs/${PN}-${UP_PV}.tar.gz > > > https://498412.bugs.gentoo.org/attachment.cgi?id=368058 -> > > > ${PN}-1.42.9-mint-r1.patch" > > > > > > Patch straight from bugzilla attachment? Huh? > > > > Why? Does it fail to download? The package is not with RESTRICT=mirror > > > > > > > > Should be moved at devspace at least. > > > > ... > > Change the header. Another question why we should keep it in bugzilla > attachment but not in filesdir for example? I'm even can do it for you if you are not mimd
"If you have to host a source file (patch or tarball) yourself, as long as it is suitable to be distributed by Gentoo Foundation (by license and legality), you're suggested to use your developer's space at dev.gentoo.org." – http://devmanual.gentoo.org/general-concepts/mirrors/#suitable-download-hosts Their is only a single Bugzilla attachment occasion in the entire Portage tree, this bug; whether Bugzilla attachments are suitable, is up for discussion. Although it is more consistent to have them on the dev space; on the one side you are safe in a "what if Bugzilla attachments ..." scenario, on the other hand you have it duplicate such that it can be recovered if one of both goes corrupt / ... Looking from another viewpoint, using Bugzilla attachments spares out extra work.
Supposedly it was moved to use SRC_URI because of, file.size 1 (38 KiB) sys-fs/e2fsprogs/files/e2fsprogs-1.41-mint.patch And yesterday, 12 Jul 2014; Samuli Suominen <ssuominen@gentoo.org> e2fsprogs-1.42.10.ebuild: Download mintlib specific patch only when required by Arfrever So now only elibc_mintlib users will actually see the download from bugzilla attachement, the impact is minimal Long as the file ends up in the mirrors, we are good: http://trumpetti.atm.tut.fi/gentoo/distfiles/e2fsprogs-1.42.9-mint-r1.patch And there it is, anyone using proper mirrors and using mintlib will get the patch just fine I've seen this done once or twice before and it was changed for no-reason, and I never figured out why... surely there has to be a reason for doing something?
As in, how is this any different from eg. pulling a specific commit from some 3rd party git www site, I've seen done numerous of times? The person doing that, expects our mirroring systems to back him up the data will never get lost by not using RESTRICT=mirror Likewise developer space is not any safer, I always delete anything-but-latest as I expect our mirrors to pick the file up, to not fill up dev.gentoo.org space (as infra has asked numerous of times for people to clean up their directories)
bugzilla is not a mirror for files i'm not even sure we should be applying this ... that is a _lot_ of crap. looks to me like the mint patch is re-implementing a fscking C library in e2fsprogs.
i've deleted the logic from e2fsprogs-1.42.10 and moved the patch to mirrors for e2fsprogs-1.42.11. but i'm re-opening the original request as i'm not sure we should even keep it. http://sources.gentoo.org/sys-fs/e2fsprogs/e2fsprogs-1.42.10.ebuild?r1=1.11&r2=1.12 http://sources.gentoo.org/sys-fs/e2fsprogs/e2fsprogs-1.42.11.ebuild?r1=1.1&r2=1.2
