public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: James Cloos <cloos@jhcloos.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use  cleanup
Date: Mon, 26 Oct 2009 19:21:08 -0400	[thread overview]
Message-ID: <m3ocntivwj.fsf@lugabout.jhcloos.org> (raw)
In-Reply-To: <4AE41EF7.5020508@gentoo.org> ("Petteri Räty"'s message of "Sun, 25 Oct 2009 11:48:39 +0200")

>>>>> "Petteri" == Petteri Räty <betelgeuse@gentoo.org> writes:

Petteri> Their maintainers should be active and switch their ebuilds to
Petteri> EAPI 2.  If they don't have an active maintainer, then do we
Petteri> want to keep live ebuilds for them around?

What possible benefit could be had from dropping ebuilds for no other
reason than their EAPI?

(Incidently, since I mentioned it as the one I remembered from the first
post, I see that git-9999 is EAPI 2 even though it does use built_with_use.)

Any mass removal should be as conservative as possible in the list of
things removed, just like anything which declares something unlawful
should be interpreted narrowly.

Your initial post indicated that you only wanted to drop ebuilds which
were unlikely to be in use by users.  Given the fact that most (all?)
live ebuilds are masked, any automated tests for the likelyhood that
an ebuild is in active use will, by definition, have false negatives
when dealing with live ebuilds.  (Where false negative means unlikely
to be in use even though it, in fact, is in use.)

And even if you did not intend to limit your removals as much as you
indicated, it is still wrong to remove anything which the userbase
actively uses.  These are not ebuilds which are broken, just ones
which, while functional, remain imperfect.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6



  reply	other threads:[~2009-10-26 23:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-29 13:32 [gentoo-dev] Unused ebuild built_with_use cleanup Petteri Räty
2009-10-07 11:21 ` Marijn Schouten (hkBst)
2009-10-08 21:29   ` Petteri Räty
2009-10-07 11:54 ` Stelian Ionescu
2009-10-08 21:34   ` Petteri Räty
2009-10-08 22:03     ` Jeremy Olexa
2009-10-08 22:22       ` Petteri Räty
2009-10-09  0:17         ` Patrick Lauer
2009-10-09 13:38           ` Petteri Räty
2009-10-08 22:25     ` Tomáš Chvátal
2009-10-09 13:41       ` Petteri Räty
2009-10-24 12:32 ` [gentoo-dev] Re: [gentoo-dev-announce] " Petteri Räty
2009-10-24 20:29   ` James Cloos
2009-10-25  9:48     ` Petteri Räty
2009-10-26 23:21       ` James Cloos [this message]
2009-10-27 13:12         ` Petteri Räty
2009-10-27  6:07       ` Ryan Hill
2009-10-27  7:02         ` Mike Frysinger
2009-10-27 13:09           ` Petteri Räty
2009-10-27 13:46             ` Mike Frysinger
2009-10-27 18:46               ` Petteri Räty
2009-10-28  2:31                 ` [gentoo-dev] " Mike Frysinger
2009-10-28  9:51                   ` Petteri Räty
2009-10-28 11:11                     ` Alexis Ballier
2009-10-30  2:29                     ` Doug Goldstein

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=m3ocntivwj.fsf@lugabout.jhcloos.org \
    --to=cloos@jhcloos.com \
    --cc=gentoo-dev@lists.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