public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Noack, Sebastian" <S.Noack@AUTOonline.de>
To: <gentoo-dev@lists.gentoo.org>
Subject: AW: [gentoo-dev] Proposal for advanced useflag-syntax
Date: Fri, 4 Aug 2006 08:21:14 +0200	[thread overview]
Message-ID: <7B97065F451A23458ED0C63B4CA5A2EA1D2914@SRV-EXCHANGE.AUTOonline.local> (raw)

> > Today the solution would be to enable the kde, qt, qt3, qt4, gtk,
etc.
> > -useflag. But this solution is crappy, because of some ebuilds for
> 
> These flags are crap at all. It already is crap that certain packages
> contain backend and frontends for several GUIs (more precisely: based
> on several widget toolkits) alltogether.  They actually should be
> different. Yeah, many packages tend to do such crap in the upstream,
> but we shouldn't let this pass into the portage tree.
> 
> For example: mplayer
> It has it's gui-less player and an gtk-based frontend in one package.
> We should split this into two packages: mplayer and gmplayer.
> The chances to get this done in the upstream *before* some major
> distro like gentoo does the split by its own are quite low.

Hey, come on. We're not Debian! Unnecessary and senseless splitting of
packages is against the philosophy of Gentoo.

> > (kde || qt4 || qt3 || qt || gtk) (arts || alsa) (asf && win32codecs)
> 
> IMHO unnecessary complexity which introduces more point of failure
> and confusion.

At the first sight this approach seems to add complexity, but actual it
would remove a lot of complexity on Gentoo systems. For example on my
own system here I have approx. 40 lines in my /etc/portage/package.use
which could be reduced to less than 10 lines by using such a syntax like
above in the /etc/make.conf for global useflag configuration.

> With you suggestion, the package maintainers have to take care of
> Grandma's special conditions. This shouldn't be their job.
> 
> Granma's Box cries for an special Grandma-Distro, Grandma-Gentoo !
> This should be maintained by an separate team, which is specialized
> on the needs of those users.

In the described scenario, it wasn't mentioned that she has a
grandchild, so where do you know from that she is a grandma? ;) Doesn't
matter, btw it was in any case just an example where such a syntax would
be useful. Another szenario would be a server with several
database-based apps on it, where an expression like "(postgres ||
mysql)" might be useful.

Regards
Sebastian Noack

-- 
gentoo-dev@gentoo.org mailing list



             reply	other threads:[~2006-08-04  6:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-04  6:21 Noack, Sebastian [this message]
2006-08-07 13:26 ` [gentoo-dev] Proposal for advanced useflag-syntax Enrico Weigelt
2006-08-07 14:53   ` Thomas Cort
2006-08-07 18:48     ` Enrico Weigelt
2006-08-07 20:09   ` Marius Mauch
2006-08-07 21:14     ` Paul de Vrieze
  -- strict thread matches above, loose matches on Subject: below --
2006-08-07 15:04 AW: " Noack, Sebastian
2006-08-07 15:21 ` Luca Barbato

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=7B97065F451A23458ED0C63B4CA5A2EA1D2914@SRV-EXCHANGE.AUTOonline.local \
    --to=s.noack@autoonline.de \
    --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