From: "Noack, Sebastian" <S.Noack@AUTOonline.de>
To: <gentoo-dev@lists.gentoo.org>
Subject: AW: [gentoo-dev] Proposal for advanced useflag-syntax
Date: Mon, 7 Aug 2006 17:04:15 +0200 [thread overview]
Message-ID: <7B97065F451A23458ED0C63B4CA5A2EA7C4A6F@SRV-EXCHANGE.AUTOonline.local> (raw)
> > > Well, I don't consider reducing complexity "frivolous" ;-o
> >
> > Which reduction for which complexity? Do you want to bring
everyone's
> > systems to a grinding halt, just because you can't understand the
> > "complexity" of useflags.
>
> I just want to keep things simple. We're talking about introducing
> new (additional) logic.
Is a need to have dozens of lines in your /etc/portage/package.use a
simple approach? Maybe it is, if for you, simplicity means only "less
number of lines of code in the core of the application". But wasn't you
the one who told me that quantity isn't the same like complexity? Well
you could say that only source code and scripts contain logic and
therefore numbers of lines in the config files doesn't means complexity,
but what do I do by the config files of portage actually? I use them for
example to instruct portage to enable useflag A but not for ebuild and
useflag B but just for ebuild b. Do you claim that this is no logic?
> Rember: we started with the thesis, "grandma wants graphical
> frontends whereever possible". This is in fact not an technical
> issue, instead a matter of personal taste, or lets say, an individual
> system configuration. Grandma wants to click, okay, so she should
> use graphical applications. She's not interested what sits behind,
> she just wants to have a buch of applications. And she also doesn't
> wann have anything to do with emerge and useflags. She just wants
> to have a choice between a bunch of end-user applications.
> That's the job of an Grandma-(sub-)distro.
That was never the point where "we" started. That was just the point,
you used to confuse this discussion. The grandma scenario should just be
a funny example for a requirement of such a advanced portage syntax I
could really need on my own systems and I'm not female, but male and not
80 but 18 years old. ;)
I know that my proposed syntax isn't a perfect solution. But I think the
current state of portage isn't a perfect solution, too. And I hoped when
I started this thread, that we will find together a good solution.
Best Regards
Sebastian Noack
--
gentoo-dev@gentoo.org mailing list
next reply other threads:[~2006-08-07 15:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-07 15:04 Noack, Sebastian [this message]
2006-08-07 15:21 ` AW: [gentoo-dev] Proposal for advanced useflag-syntax Luca Barbato
2006-08-07 20:18 ` Enrico Weigelt
-- strict thread matches above, loose matches on Subject: below --
2006-08-04 6:21 AW: " Noack, Sebastian
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=7B97065F451A23458ED0C63B4CA5A2EA7C4A6F@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