[gentoo-dev] Ebuild behaviour?

[gentoo-dev] Ebuild behaviour?

[Stewart]

Hello, all;

I was wondering if there exists any formal policy on the 
addition/removal (emphasis on the latter) of ebuilds?

Two examples that come immediately to mind in recent past are LICQ and 
Mozilla. In the case of LICQ, a 1.2.6 ebuild was committed which did not 
work (for whatever reason a copy of the 1.2.4-r2 ebuild failed to 
install the plugins correctly, rendering the GUI unusable), and at the 
same time - before any testing was done to 1.2.6 - the (stable, tested) 
1.2.4-r2 ebuild, and all prior to it, were removed from the tree.

In the case of Mozilla, its ebuilds have remained behind the releases 
(alpha/beta/release candidate) for some time, remaining fixed at 1.3. In 
a previous rsync I noticed a 1.4b ebuild, but in a subsequent rsync that 
ebuild was removed from the tree. I was anxious to hack away at it and 
see if it would work and possibly be portable for the 1.4rc1 version.

So what is the policy on removing stable, tested ebuilds, and even for 
removing newer ebuilds which haven't had a chance to be tested? In the 
case of LICQ, shouldn't that be handled by ~arch? In the case of 
Mozilla, package.mask until the ebuild installed, and ~arch afterwards 
for testing?

Portage is technologically fantastic, but I'm afraid that if the means 
aren't used properly, we may find ourselves with a frustrated user (and 
developer) base. :/

Thoughts? Opinions?

-- 
http://www.snerk.org/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ebuild behaviour?

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

Speaking from personal experience, sometimes an ebuild needs to be pulled when, no matter how new it is, the source it points to no longer exists (look at dev-perl sometime if that doesn't make sense)

On Sun, 01 Jun 2003 13:57:08 -0400
Stewart <bdlists@snerk.org> wrote:

> Hello, all;
> 
> I was wondering if there exists any formal policy on the 
> addition/removal (emphasis on the latter) of ebuilds?
> 
> Two examples that come immediately to mind in recent past are LICQ and 
> Mozilla. In the case of LICQ, a 1.2.6 ebuild was committed which did not 
> work (for whatever reason a copy of the 1.2.4-r2 ebuild failed to 
> install the plugins correctly, rendering the GUI unusable), and at the 
> same time - before any testing was done to 1.2.6 - the (stable, tested) 
> 1.2.4-r2 ebuild, and all prior to it, were removed from the tree.
> 
> In the case of Mozilla, its ebuilds have remained behind the releases 
> (alpha/beta/release candidate) for some time, remaining fixed at 1.3. In 
> a previous rsync I noticed a 1.4b ebuild, but in a subsequent rsync that 
> ebuild was removed from the tree. I was anxious to hack away at it and 
> see if it would work and possibly be portable for the 1.4rc1 version.
> 
> So what is the policy on removing stable, tested ebuilds, and even for 
> removing newer ebuilds which haven't had a chance to be tested? In the 
> case of LICQ, shouldn't that be handled by ~arch? In the case of 
> Mozilla, package.mask until the ebuild installed, and ~arch afterwards 
> for testing?
> 
> Portage is technologically fantastic, but I'm afraid that if the means 
> aren't used properly, we may find ourselves with a frustrated user (and 
> developer) base. :/
> 
> Thoughts? Opinions?
> 
> -- 
> http://www.snerk.org/
> 
> 
> --
> gentoo-dev@gentoo.org mailing list

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]