* [gentoo-dev] Broken ebuilds
@ 2013-10-15 17:04 P.C.
2013-10-15 17:31 ` Rich Freeman
2013-10-15 17:32 ` [gentoo-dev] " Tom Wijsman
0 siblings, 2 replies; 4+ messages in thread
From: P.C. @ 2013-10-15 17:04 UTC (permalink / raw
To: gentoo-dev
Hi,
I've been trying to set up a Gentoo system using an older version of
the portage tree [1]. Most of it goes well, but some ebuilds stopped
merging correctly. Namely, it's Python 2.7. While merging, it
requests the following file:
http://gentoo.ussg.indiana.edu/distfiles/python-gentoo-patches-2.7.3-1.tar.bz2
which is a 404, therefore forcing me to install Python manually.
Is that "ebuild decay" intentional? How long I can expect ebuilds to
stay useful?
Before someone suggests I should upgrade to current snapshot - my use
case depends on pkgcore which doesn't support newer portage tree.
Is this broken ebuild a bug?
Cheers,
P.C.
[1] Portage tree from 2013-02-07
http://git.calculate.ru/?p=calculate/portage.git;a=snapshot;h=65adf3c525b50d70792d5c89814a17a7712447fc;sf=tgz
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] Broken ebuilds
2013-10-15 17:04 [gentoo-dev] Broken ebuilds P.C.
@ 2013-10-15 17:31 ` Rich Freeman
2013-10-16 3:48 ` [gentoo-dev] " Duncan
2013-10-15 17:32 ` [gentoo-dev] " Tom Wijsman
1 sibling, 1 reply; 4+ messages in thread
From: Rich Freeman @ 2013-10-15 17:31 UTC (permalink / raw
To: gentoo-dev
On Tue, Oct 15, 2013 at 1:04 PM, P.C.
<gedeli.pasc.pcz@porcupinefactory.org> wrote:
>
> Is that "ebuild decay" intentional? How long I can expect ebuilds to
> stay useful?
There really are no guarantees for anything not in the current tree.
The EAPIs/eclasses themselves are pretty well-designed and while
breakage over a period of years is likely, over a period of months it
is not.
However, your problem is that a patch set was hosted only on mirrors
and not anywhere more permanent. In general mirror-only patch hosting
is frowned upon - they should have a SRC_URI that doesn't start with
mirror://. However, that doesn't guarantee that those patches will be
hosted forever. I keep them in my gentoo webspace and don't really
rush to clean them up, but that space is not archived anywhere.
Google suggests that you might be in luck if you manually fetch your
file from here:
http://dev.gentoo.org/~floppym/python/
I think there might have been a little talk about better solutions for
file-hosting that might address some of these problems, but I'm not
aware of any serious work being done.
Rich
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] Broken ebuilds
2013-10-15 17:04 [gentoo-dev] Broken ebuilds P.C.
2013-10-15 17:31 ` Rich Freeman
@ 2013-10-15 17:32 ` Tom Wijsman
1 sibling, 0 replies; 4+ messages in thread
From: Tom Wijsman @ 2013-10-15 17:32 UTC (permalink / raw
To: gedeli.pasc.pcz; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
Hello P.C.
The distfiles mirroring system keeps distfiles around for as long as
the ebuilds are in the Portage tree that refer to them; once all
ebuilds referring to a distfile are removed, the distfile will be
removed from the mirroring system in half a week or so. *
Long story short, if you want to have an older version of the Portage
tree you will need to have distfiles as well; otherwise you will depend
on what upstream and our developer space still provide.
* Based on comparing http://dev.gentoo.org/distfile-mirroring/ with the
dead files on http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : TomWij@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [gentoo-dev] Re: Broken ebuilds
2013-10-15 17:31 ` Rich Freeman
@ 2013-10-16 3:48 ` Duncan
0 siblings, 0 replies; 4+ messages in thread
From: Duncan @ 2013-10-16 3:48 UTC (permalink / raw
To: gentoo-dev
Rich Freeman posted on Tue, 15 Oct 2013 13:31:12 -0400 as excerpted:
> On Tue, Oct 15, 2013 at 1:04 PM, P.C.
> <gedeli.pasc.pcz@porcupinefactory.org> wrote:
>>
>> Is that "ebuild decay" intentional? How long I can expect ebuilds to
>> stay useful?
>
> There really are no guarantees for anything not in the current tree. The
> EAPIs/eclasses themselves are pretty well-designed and while breakage
> over a period of years is likely, over a period of months it is not.
>
> However, your problem is that a patch set was hosted only on mirrors and
> not anywhere more permanent. In general mirror-only patch hosting is
> frowned upon - they should have a SRC_URI that doesn't start with
> mirror://. However, that doesn't guarantee that those patches will be
> hosted forever. I keep them in my gentoo webspace and don't really rush
> to clean them up, but that space is not archived anywhere.
>
> Google suggests that you might be in luck if you manually fetch your
> file from here:
> http://dev.gentoo.org/~floppym/python/
>
> I think there might have been a little talk about better solutions for
> file-hosting that might address some of these problems, but I'm not
> aware of any serious work being done.
>
> Rich
Note that mirror-only patch hosting isn't just frowned upon, it can at
times be a license violation as well. As a foundation trustee last year,
Rich, you're very likely aware of this already, but for others...
It's worth noting that this sort of thing at at least one point in the
past caused gentoo to be in violation of the GPL. That doesn't apply in
this case as python isn't GPL (tho I've not looked; it may have a similar
license clause), but it's worth being aware of for GPLed packages at
least.
In the normal case gentoo's source-based which means the relevant GPL
binary-distribution clauses don't apply, but we do distribute live-CDs
and sometimes binary-package CDs, with binary packages/executables on
both. For at least the (L)GPLed packages, that means we either have to
be very careful to offer all the sources at the same time and in the same
manner as we do the binaries (if for instance we're handing out live-cds
at a conference, having a cd of the relevant sources available as well
fits the bill, whether people actually take it or not is then their
choice, we offered it at the same time and in the same manner), *OR* we
must make *ALL* relevant sources (including any patches applied to that
specific binary build) available for a period of at least three years
from when we last distributed the binaries.
That's the GPL2 terms AFAIK. GPL3 is similar but I'm not as familiar
with the specific conditions.
Since three years is a long time in gentoo terms and things can get lost,
ensuring that we're making sources available at/in the same time/place/
manner as we're distributing the binaries is by *FAR* the easiest and
legally safest way to go.
That said, we really SHOULD be covering our three-year bases as well,
just in case, and have an archive for such patches. Can't they be
checked into some cvs/git/whatever tree somewhere too, just as are the
ebuild and eclass sources, so if that request does actually come, it's a
"simple" matter of checking out the tree at the appropriate date/time,
tarballing it up, and shipping it as-is? That'd certainly include all
sorts of unrelated patches for other packages as well, but the ones
required by the license and thus the law would be included. And once
it's setup, there's actually little reason to limit it to GPLed packages
or to three years. Just make read-only access to that repo as public as
access to our normal sources, and we should be good to go... it'll be
self-service so actually having to manually deal with such a request will
be far less likely, but possible as well, should it be needed.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-10-16 3:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-15 17:04 [gentoo-dev] Broken ebuilds P.C.
2013-10-15 17:31 ` Rich Freeman
2013-10-16 3:48 ` [gentoo-dev] " Duncan
2013-10-15 17:32 ` [gentoo-dev] " Tom Wijsman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox