AW: [gentoo-dev] Proposal for advanced useflag-syntax

AW: [gentoo-dev] Proposal for advanced useflag-syntax

[Noack, Sebastian]

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

Re: AW: [gentoo-dev] Proposal for advanced useflag-syntax

[Luca Barbato]

Noack, Sebastian wrote:
> 
> 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?

I claim that is simple and you should wait at least 24 h before posting
on -dev.

> 
> 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. ;)

Poor you.

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

You can just write something like flagedit for your extreme uses.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Proposal for advanced useflag-syntax

[Enrico Weigelt]

* Noack, Sebastian <S.Noack@AUTOonline.de> schrieb:

<snip>

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

No, that's just quantity of information. Linear data, just like an
list of addresses or phone numbers. There are no rules in it.

The rules just exist in your mind, not in the portage system.
And if you like to modelize them, it should be done separately 
on top of portage.

Okay, let's assume for a while, we've got your additional rules
in the portage system. Someone has to make the decision about 
which frontends to prefer over others. If it's you, then you'll 
be happy with that, since you'll most likely decide the way you
like, but others may be very unhappy with your decisions. On the
other hand, with anyone else making this decision, there's plenty
risk, you'll be unhappy with his decision.

I see big flamewars coming on that. 
Remember the sunrise affair(s) ? 

<snip>

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

Maybe I missed something, but this was the first posting I read on
that topic. 

> 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. ;)

IMHO an bad chosen one, as I take such examples seriously.

<snip>

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

IMHO, the problem isn't yet defined cleanly enough to have a chance
on an good solution.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

AW: [gentoo-dev] Proposal for advanced useflag-syntax

[Noack, Sebastian]

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