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