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