public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Stewart <bdlists@snerk.org>
To: gentoo-dev@gentoo.org
Subject: [gentoo-dev] Ebuild behaviour?
Date: Sun, 01 Jun 2003 13:57:08 -0400	[thread overview]
Message-ID: <3EDA3E74.5030801@snerk.org> (raw)

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


             reply	other threads:[~2003-06-01 17:56 UTC|newest]

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

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=3EDA3E74.5030801@snerk.org \
    --to=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