public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Cummings <mcummings@gentoo.org>
To: Stewart <bdlists@snerk.org>
Cc: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Ebuild behaviour?
Date: Sun, 1 Jun 2003 14:54:32 -0400	[thread overview]
Message-ID: <20030601145432.13f52a68.mcummings@gentoo.org> (raw)
In-Reply-To: <3EDA3E74.5030801@snerk.org>

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

      reply	other threads:[~2003-06-01 18:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-01 17:57 [gentoo-dev] Ebuild behaviour? Stewart
2003-06-01 18:54 ` Michael Cummings [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030601145432.13f52a68.mcummings@gentoo.org \
    --to=mcummings@gentoo.org \
    --cc=bdlists@snerk.org \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox