[gentoo-dev] Re: Broken ebuilds

[Duncan]

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@××××××××××××××××.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