[gentoo-dev] Broken ebuilds

[gentoo-dev] Broken ebuilds

[P.C.]

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

Re: [gentoo-dev] Broken ebuilds

[Rich Freeman]

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

Re: [gentoo-dev] Broken ebuilds

[Tom Wijsman]

[-- 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 --]

[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@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