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