public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alistair Bush <ali_bush@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Amount of useflags enabled by default
Date: Sat, 24 Oct 2009 13:55:34 +1300	[thread overview]
Message-ID: <200910241355.35305.ali_bush@gentoo.org> (raw)
In-Reply-To: <4AE1E033.3030707@gentoo.org>

> Hi,
> 
> i would like to start a discussion about reducing the amount of
>  default-enabled USE flags in profiles, especially in inherited basic
>  profiles.

Sounds like a reasonable idea to me, for the base profiles at least.

> In addition, i see a trend to enabled more more more USE flags (either over
>  profiles or via IUSE +flag). Whats the reason for forcing a big load of
>  default enabled USE flags on every user including more dependencies, more
>  compile time, more wasted disk space and more possible vulnerabilities
>  except some users, who complain about a missing feature and are not able
>  to think and enable a USE flag for that feature?
> 

".... who complain about a enabled feature and are not able to think and 
disable a USE flag for that feature?"

What a couple of changes make....

It would be nice if we actually documented why they were enabled.  Does the 
use flag enable significant functionality that would otherwise make the software 
less useful.

I believe we should be trying to find a nice 'middle of the road' balance.   DE 
"related" use flags should be enabled in profiles ( unless of coarse they 
package is already DE related e.g if a kde package has a use flag for kde's 
sound system, this could be enabled at a package level while a package with a 
kde use flag should not default enable it.).

So,  if we were looking at what use flags ppl are enabling/disabling we should 
be seeing similar numbers for the "+'s" and the "-'s".  Not an easy thing to 
do, I admit.   Would be interesting if something like Color Graphing [1] or 
some algorithm could be used to determine whether a use flag should be enabled 
in a profile (including which profile)/package.  Maybe we should have some 
addition metadata for use flags.  Like a category/type/blah/blee. As an example 
we could have a category of DE containing kde/gnome/etc.  How do we know that 
the dirac use flag is codec related without knowing what dirac is?


Alistair


[1] http://en.wikipedia.org/wiki/Graph_coloring



  parent reply	other threads:[~2009-10-24  0:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-23 16:56 [gentoo-dev] Amount of useflags enabled by default Thomas Sachau
2009-10-23 19:32 ` Sebastian Pipping
2009-10-24 16:14   ` Thomas Sachau
2009-10-23 19:54 ` Petteri Räty
2009-10-24 16:03   ` Pacho Ramos
2009-10-24 16:24   ` Thomas Sachau
2009-10-24 19:38     ` William Hubbs
2009-10-24  0:55 ` Alistair Bush [this message]
2009-10-24 16:35   ` Thomas Sachau
2009-11-06 23:40     ` Ed W
2009-11-07  7:46       ` [gentoo-dev] " Duncan

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=200910241355.35305.ali_bush@gentoo.org \
    --to=ali_bush@gentoo.org \
    --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