From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id EDE851381F3 for ; Wed, 16 Oct 2013 03:49:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 304B7E09F3; Wed, 16 Oct 2013 03:49:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A59E8E09ED for ; Wed, 16 Oct 2013 03:49:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D144133F05C for ; Wed, 16 Oct 2013 03:49:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5.5 tests=[AWL=-0.976, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRvvnacMJm2E for ; Wed, 16 Oct 2013 03:49:17 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 8298733F05A for ; Wed, 16 Oct 2013 03:49:15 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VWI6j-00072w-5a for gentoo-dev@gentoo.org; Wed, 16 Oct 2013 05:49:13 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Oct 2013 05:49:13 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Oct 2013 05:49:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Broken ebuilds Date: Wed, 16 Oct 2013 03:48:54 +0000 (UTC) Message-ID: References: <20131015190422.6f2570f4@porcupinefactory.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 6e6fd84 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 7dff09fb-9292-403a-acf0-a2c76b267bf2 X-Archives-Hash: f20cdcffbbafb167f753d6e55dba2d6e 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. > 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