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

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

[Enrico Weigelt]

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

<snip>

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

I don't think "we are not xyz" is a good argumentation in 
technical discussions.

At this point, Debian is actually doing good work. The bad thing is 
that those things don't get neither into the upstrem nor other
distros. That's exactly what my OSS-QM project is for.

<snip>

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

You shouldn't mix up quantity with complexity.

If you make handling of badly designed code easier, you take presure
from the actual developers.

<snip>

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

So no special Grandma-support is needed at all.

<snip>

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

Aehm, you hopefully know that they don't have very much in common. 
Please give me an example, where this would be should be useful.

RDBMS'es aren't actually things we you could say "choose what you
like, doesn't matter which one". Yeah, would be nice if it was
so, but that's just a nice dream.


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

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

[Thomas Cort]

[-- Attachment #1: Type: text/plain, Size: 341 bytes --]

On Mon, 7 Aug 2006 15:26:44 +0200
Enrico Weigelt <weigelt@metux.de> wrote:

> The bad thing is that those things don't get neither into the upstrem
> nor other distros.

      ^--- This should be a warning flag ---^

If other distros aren't doing it and upstream isn't doing it, then it
may no be that great of an idea.

-Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Enrico Weigelt]

* Thomas Cort <tcort@gentoo.org> schrieb:
> On Mon, 7 Aug 2006 15:26:44 +0200
> Enrico Weigelt <weigelt@metux.de> wrote:
> 
> > The bad thing is that those things don't get neither into the upstrem
> > nor other distros.
> 
>       ^--- This should be a warning flag ---^
> 
> If other distros aren't doing it and upstream isn't doing it, then it
> may no be that great of an idea.

Not really. Simply seems that no one else cares about the Debian 
patches, since they don't do enough publicity. They simply fix
some problems at their side and are done with this. Same for other
many distros. 


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

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

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

On Mon, 7 Aug 2006 15:26:44 +0200
Enrico Weigelt <weigelt@metux.de> wrote:

> * Noack, Sebastian <S.Noack@AUTOonline.de> schrieb:
> 
> <snip>
> 
> > Hey, come on. We're not Debian! Unnecessary and senseless 
> > splitting of packages is against the philosophy of Gentoo.
> 
> I don't think "we are not xyz" is a good argumentation in 
> technical discussions.
> 
> At this point, Debian is actually doing good work. The bad thing is 
> that those things don't get neither into the upstrem nor other
> distros. That's exactly what my OSS-QM project is for.

*sigh*, if you want to use a source based Debian (as the combination of
all your posts seems to indicate) then do so, stop trying to convert
Gentoo into that. Or create your own private fork.
I start to get *really* annoyed by your overall behavior in the last
weeks, and I can tell you that takes quite a bit of effort.
Really, re-evaluate your motivation for being on this list.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On Monday 07 August 2006 22:09, Marius Mauch wrote:
>
> *sigh*, if you want to use a source based Debian (as the combination of
> all your posts seems to indicate) then do so, stop trying to convert
> Gentoo into that. Or create your own private fork.
> I start to get *really* annoyed by your overall behavior in the last
> weeks, and I can tell you that takes quite a bit of effort.
> Really, re-evaluate your motivation for being on this list.
>
> Marius

I second this as should be clear from my earlier rant. Enrico should stop 
barking about how everything in gentoo is broken without having actually been 
active and built up a reputation.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

[gentoo-dev] Proposal for advanced useflag-syntax

[Noack, Sebastian]

Hi,

following szenario: Somebody installs a kde desktop and because of it is
an 80 years old woman ;), she wants to have graphical frontends where
ever possible.

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
example app-office/openoffice have support for multiple widget libraries
and because our 80 years old female person has a kde desktop, she would
prefer kde-support about gtk+. Today she would have to decide if she
wants to make an entry in /etc/portage/package.use for each ebuild that
comes with multiple widget library support or if she wants to compile
each such ebuild preventive with support for every available widget
library, which would be against the sense of useflags.

To prevent such szenarios I propose following extended syntax for
useflag configuration:

(kde || qt4 || qt3 || qt || gtk) (arts || alsa) (asf && win32codecs)

This expression would affect that only if a kde-useflag isn't provided
the qt4 useflag, becomes used and if this isn't also provided the qt3
useflag becomes used and so on. The same for arts and alsa, where it is
nonsense to support both but better to support arts. And the last
segment of this expression would affect that win32codecs and asf becomes
enabled for each ebuild that supports asf. This would for example be
useful in the case of media-libs/xine-lib if you want have asf-support
but you want avoid win32codecs as much as possible, because of xine-lib
needs win32codecs to support asf.

Best Regards
Sebasitan Noack

-- 
gentoo-dev@gentoo.org mailing list

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

[Luca Barbato]

Enrico Weigelt wrote:

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

We do not split packages for frivolous reasons. The only accepted
exception is when a kernel module and an application requiring lots of
time to build are bundled together.

> Some 
> people @mplayerhq are quite aeh, unfortunate, about changes in the
> build procedure. Maybe you like to have a look at the discussion 
> about my patches introducing pkg-config utilization.

I don't see how it is related.

lu

PS: all mplayer front-ends use/(should use) the slave-mode ipc, gmplayer
is deprecated and will be replaced by another front-end using slave-mode
as the others.

-- 

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

On Monday 07 August 2006 15:16, Enrico Weigelt wrote:
> * Luca Barbato <lu_zero@gentoo.org> schrieb:
>
> <snip>
>
> > > 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.
> >
> > We do not split packages for frivolous reasons.
>
> 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. Useflags are one of the distinguishing features of gentoo. Now you 
opt to do away with them. I do not see the reason. It is also against the 
gentoo philosophy of offering software the way upstream provides it.

>
> <snip>
>
> > > Some
> > > people @mplayerhq are quite aeh, unfortunate, about changes in the
> > > build procedure. Maybe you like to have a look at the discussion
> > > about my patches introducing pkg-config utilization.

pkg-config is a broken concept. Libraries themselves should state dependency 
information. Pkg-config is a "solution" that introduces at least as many 
problems as it solves. Only libtool (esp. old versions) is worse in it's 
incomplete use of the linker and the way it encourages broken library 
linking.

> That's the right ways. And so gmplayer stuff should be dropped
> completely. If you like, I'll sit down and fix the ebuilds.

First fix your attitude problem, then come with good suggestions stated in a 
more friendly way.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

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

[Enrico Weigelt]

* Paul de Vrieze <pauldv@gentoo.org> schrieb:

<snip>

> > 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. This has to be maintained. And it doesn't 
actually *solve* the problem which is this discussion was started.

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.

Okay, let's say we want to intruduce an meta-useflag for "GUI"
(although having additional GUIs in the same package as the 
backend isn't what I consider clean design). If there's just *one*
than it's easy - just an alias. But what's if we have more ?
Who makes the decision, which one to take ? Based on what rules ?

> Useflags are one of the distinguishing features of gentoo. 

Yes. For optional features. Additional programs aren't features of
some other program, but additional programs. 

<snip>

> It is also against the gentoo philosophy of offering software the 
> way upstream provides it.

Ah, and this philosophy is more important than quality and 
maintainability ?

<snip>

> > > > Some
> > > > people @mplayerhq are quite aeh, unfortunate, about changes in the
> > > > build procedure. Maybe you like to have a look at the discussion
> > > > about my patches introducing pkg-config utilization.
> 
> pkg-config is a broken concept.

Ah ? 

I consider it *very* clean. What could be easier than have an 
consistent database which *knows* what's installed on the system 
instead of having to run lots of esoteric tests which shall *guess* 
it somehow ?!

If necessary, this database query can be intercepted easily. With
the esoteric testing its very complicated or at least work intensive.

BTW: have to ever tried to crosscmompile a whole system in a clean
sysroot'ed environment ?

<snip>

> Libraries themselves should state dependency information. 

Hah, but only *should*, not actually *do*.
Okay, ELF so's can contain such information, but that's only a little
part of an library. There's much, much more. 

Well, how would you get certain search pathes (-I, -L, ...) 
additional includes, dependency info for evrything but elf-so, ie .a ?

> Pkg-config is a "solution" that introduces at least as many 
> problems as it solves. 

Example ?

<snip> 

> Only libtool (esp. old versions) is worse in it's incomplete use 
> of the linker and the way it encourages broken library linking.

Libtool is isn't just broken, it's totally misconception. 
But that's another story and has *nothing* to do with pkg-config.


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

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

[Alec Warner]

Enrico Weigelt wrote:
> * Paul de Vrieze <pauldv@gentoo.org> schrieb:
> 
> <snip>
> 
>>> 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. This has to be maintained. And it doesn't 
> actually *solve* the problem which is this discussion was started.
> 
> 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.
> 

Bad example, as Gentoo generally requires knowledge of the system and
the command line interface; unless you think grandma can update her
toolchain properly with no issues.  I don't think anyone at this point
would hand Gentoo to grandma; and I don't think anyone has that goal.
Mostly we just want an easy to maintain system.  See that word,
maintain; generally means the maintainer knows what they are doing.

> Okay, let's say we want to intruduce an meta-useflag for "GUI"
> (although having additional GUIs in the same package as the 
> backend isn't what I consider clean design). If there's just *one*
> than it's easy - just an alias. But what's if we have more ?
> Who makes the decision, which one to take ? Based on what rules ?
> 

The packages maintainer for Gentoo typically makes the choice on how
something is deployed in Gentoo.

>> Useflags are one of the distinguishing features of gentoo. 
> 
> Yes. For optional features. Additional programs aren't features of
> some other program, but additional programs. 

I would gather for many packages that a gui is a optional feature.
Also this is not a hard and fast rule (and was never meant to be).

> 
> <snip>
> 
>> It is also against the gentoo philosophy of offering software the 
>> way upstream provides it.
> 
> Ah, and this philosophy is more important than quality and 
> maintainability ?

This *philosophy* is a core value of gentoo.  That would be like saying
we should build binary packages for everything because it's easier to
maintain and gives us a higher quality distribution.

Pardon my french, but fuck that.

-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

On Monday 07 August 2006 16:18, Enrico Weigelt wrote:
> I just want to keep things simple. We're talking about introducing
> new (additional) logic. This has to be maintained. And it doesn't
> actually *solve* the problem which is this discussion was started.

Removing the stuff from the ebuild and maintaining two ebuilds that must be 
synchronized with eachother is complex.
>
> 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.

gentoo is not a grandma distro and does not try to be so.

>
> Okay, let's say we want to intruduce an meta-useflag for "GUI"
> (although having additional GUIs in the same package as the
> backend isn't what I consider clean design). If there's just *one*
> than it's easy - just an alias. But what's if we have more ?
> Who makes the decision, which one to take ? Based on what rules ?

The council makes the decisions.

> Yes. For optional features. Additional programs aren't features of
> some other program, but additional programs.

You should read up on your history. Useflags are as well for additional 
programs as for features. This is especially true when things should be kept 
together as they are tightly coupled.

> Ah, and this philosophy is more important than quality and
> maintainability ?

You fail to see that what we do has quality and is certainly maintainable.

> > pkg-config is a broken concept.
>
> Ah ?
>
> I consider it *very* clean. What could be easier than have an
> consistent database which *knows* what's installed on the system
> instead of having to run lots of esoteric tests which shall *guess*
> it somehow ?!

The tests don't actually guess. The main problem though is that pkg-config 
encourages wrong linking. Linking should happen properly such that libraries 
link in their own dependencies, so that library users don't have to.

> If necessary, this database query can be intercepted easily. With
> the esoteric testing its very complicated or at least work intensive.

There is nothing esoteric about checking for the existence of libfoo.

> Well, how would you get certain search pathes (-I, -L, ...)
> additional includes, dependency info for evrything but elf-so, ie .a ?

The thing is you don't should not link the dependent libs of a dependency. 
That way you don't need to recompile if (say gtk was compiled with a new 
libpng version)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

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

[Enrico Weigelt]

* Paul de Vrieze <pauldv@gentoo.org> schrieb:

<snip>

> > I just want to keep things simple. We're talking about introducing
> > new (additional) logic. This has to be maintained. And it doesn't
> > actually *solve* the problem which is this discussion was started.
> 
> Removing the stuff from the ebuild and maintaining two ebuilds that 
> must be synchronized with eachother is complex.

Where exactly have the two packages gtk1 and gtk2 to be synchonized ?

<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.
> 
> gentoo is not a grandma distro and does not try to be so.

No, it is not, and it shall not.
But this was example at the start of this whole discussion.

I understand the intentions to make such things easier, 
but I really doubt it will be an *real* solution. 

If you see it as a huge set of possible system configurations 
(defined by list of installed packages, versions, useflags, ...), 
each individual configuration as an element of this set, then our 
Grandma-scenario is an subset: we cut out a bunch of elements 
which may be interesting for the intended audience.

So in other words: we need some kind of preselection.
Default useflags and useflag aliases on profile basis.

Maybe there could be an extra file, ie. package.use.alias

foo/bar		gui=gtk
blah/blubb	gui=qt2
...

I'm not sure if this alias handling should be done by emerge, 
or better by some frontend (I learned that explicit downgrade 
warnings should be done by an frontend, so why should useflag
aliasing shouldn't ?). But I'm sure these information should
not go directly to the ebuilds.

<snip>

> > Okay, let's say we want to intruduce an meta-useflag for "GUI"
> > (although having additional GUIs in the same package as the
> > backend isn't what I consider clean design). If there's just *one*
> > than it's easy - just an alias. But what's if we have more ?
> > Who makes the decision, which one to take ? Based on what rules ?
> 
> The council makes the decisions.

How detailed is this decision ? 
Global for all or by package ?

<snip>
 
> > Yes. For optional features. Additional programs aren't features of
> > some other program, but additional programs.
> 
> You should read up on your history. Useflags are as well for additional 
> programs as for features. This is especially true when things should 
> be kept together as they are tightly coupled.

This soon gets confusing for many people. See the dhcp thread.
There're lots of discussions about the server and client useflags.
Could have been done easily by splitting off into two packages,
one for server, one for client and providing an meta package for
people who like to have both.

<snip>

> > I consider it *very* clean. What could be easier than have an
> > consistent database which *knows* what's installed on the system
> > instead of having to run lots of esoteric tests which shall *guess*
> > it somehow ?!
> 
> The tests don't actually guess. 

Really ? 

In the recent years I had do lots of fixes in many autoconf stuff
(autotools itself as well as configure.ac's) to get them working
on situations where building and target systems aren't the same.
Obviously this is not the case for gentoo (it's an self-building
distro, not system A building for an completely different system B),
so you probably don't get involved in such problems.

For example, if you're building in an sysroot'ed environment, you
have tweak patches - "/" mostly doesn't mean the running systems's 
root, but the target system image. 

Many packages provide their own autoconf macros for detecting if 
the package is installed. In 99% they don't provide more information
than can be found in an .pc file. But they introduce additional 
complexity, could have been nailed down by an simple pkg-config 
query. You don't even need autoconf for that - can also directly 
be done within an makefile. But if each package provides its own 
implementation, they all have to be tweaked by their own for such
non-stardard situations. When using pkg-config, there's only 
one central point to intercept. 

If you regenerate the configure stuff of some package A which *may*
require some package B (if the appropriate feature is selected),
you will need to have the package B installed, so the macros can
be found. Not because it will be actually required, but just for 
getting the configure script built. Okay, some packages ship a
copy of the macros by their own, but this again is additional 
complexity: the package developers have to keep it up-to-date.

<snip>

> The main problem though is that pkg-config encourages wrong linking. 

No, it doesn't encourage it. Maybe it takes some presure to do so.
But the individual autoconf macros do the same.

BTW: there are scenarios, where such dependency information within
the shared objects are not feasible. For example, if you don't 
*want* to have strict dependency graphs, instead several shared
objects making up an (virtual) library. Most of these cases could 
be circumvented by very clean and strict design from gound up.
C is not Oberon. C allows such non-strict linking, like it or not.

If you really want to *encourage* this strictness, there are far
better concepts, you could go in an direction like

    http://wiki.metux.de/public/TreeBuild 

and get rid off much, much complexits immediately.

But I had to learn, it's not the question what *could* be done,
instead what's *actually* done. People don't seem to like those
approaches very much. I tried to port many packages to treebuild,
but just me alone isn't far enough manpower for that.
So I tried to get some steps back and repair packages to at least
go away from individual macros.


BTW: you didn't answer how you wanna get the dependencies solved
with static archives or on platforms which don't provide these
dependency information. Maybe I'm not up-to-date, but I didn't
ever see dll dependencies on win32.

> > If necessary, this database query can be intercepted easily. With
> > the esoteric testing its very complicated or at least work intensive.
> 
> There is nothing esoteric about checking for the existence of libfoo.

You miss the question of installation pathes. Any you miss the 
dozens of --with-libfoo=... options.

Obviously there's a strong interest that certain libraries can be
installed in specific locations (ie. for MVCC, etc) and client
packages need to find them.

BTW: an pkg-config query is much, much faster than building a whole
hello-world just for checking if some package is there.

And another scenario for pkg-config: packages are not necessarily
equal with (shared) libraries. For example the -proto packages 
of Xorg. How do you intend to handle that ?

<snip>

> > Well, how would you get certain search pathes (-I, -L, ...)
> > additional includes, dependency info for evrything but elf-so, ie .a ?
> 
> The thing is you don't should not link the dependent libs of a dependency. 
> That way you don't need to recompile if (say gtk was compiled with a new 
> libpng version)

Yes, of course. Such double-dependencies are bad. But it's not an 
pkg-config issue. If people write bad .pc files, you really can't 
blame pkg-config for that. It has proper dependency handling.

Again, you missed to answer my question: how to you intend to
handle non-default search pathes ?


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

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

[Simon Stelling]

Enrico Weigelt wrote:
> foo/bar		gui=gtk
> blah/blubb	gui=qt2

bleh/enrico	gui=qt4

SCNR

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

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

[Enrico Weigelt]

* Simon Stelling <blubb@gentoo.org> schrieb:
> Enrico Weigelt wrote:
> >foo/bar		gui=gtk
> >blah/blubb	gui=qt2
> 
> bleh/enrico	gui=qt4

s/qt4/ncurses/;


;-P

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

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

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

Enrico Weigelt wrote:
> Maybe there could be an extra file, ie. package.use.alias
> 
> foo/bar		gui=gtk
> blah/blubb	gui=qt2
> ...
> 
> I'm not sure if this alias handling should be done by emerge, 
> or better by some frontend (I learned that explicit downgrade 
> warnings should be done by an frontend, so why should useflag
> aliasing shouldn't ?). But I'm sure these information should
> not go directly to the ebuilds.

Look, you really didn't invent anything new (refer fex. to GLEP-29)

- http://www.gentoo.org/proj/en/glep/glep-0029.html
- http://marc.theaimsgroup.com/?t=109802333600005&r=1&w=2

Unless you have some reference implementation that doesn't suck and does
address all the concerns why this has been withdrawn, there's no point
in continuing this discussion and flooding the mailing list. If you read
on the above, it turned out that instead of simplification things can
become a lot more complicated and confusing instead.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Simon Stelling]

Enrico Weigelt wrote:
> 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.

Not quite true. In reality, they're just the same. mplayer simply checks whether 
it was called as mplayer or gmplayer. So you not only have two programs in one 
package, but even in one binary. Changing this behaviour has nothing to do with 
packaging and is really upstream's responsibility, IMHO.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Fri, Aug 04, 2006 at 09:54:18AM +0200, Simon Stelling wrote:
> Enrico Weigelt wrote:
> >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.
> 
> Not quite true. In reality, they're just the same. mplayer simply checks 
> whether it was called as mplayer or gmplayer. So you not only have two 
> programs in one package, but even in one binary. Changing this behaviour 
> has nothing to do with packaging and is really upstream's responsibility, 
> IMHO.

Additionally... once you start down that path, the changes to pkgs 
become less then minor.  Some are simple, some ain't.

Personally, I hate that approach- ignoring any political/warring 
idiocy, my main issue with debian is the choice to split upstream 
packages into multiple sub packages.  Makes things a pain in the ass 
to what you want/need and makes for fun lock-step dependencies between 
the subpackages.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Enrico Weigelt]

* Brian Harring <ferringb@gmail.com> schrieb:

<snip>

> Additionally... once you start down that path, the changes to 
> pkgs become less then minor.  Some are simple, some ain't.

If it's required to get them clean, then it shall be done.
(I'm actually doing thins @ oss-qm)

<snip>
 
> Personally, I hate that approach- ignoring any political/warring 
> idiocy, my main issue with debian is the choice to split upstream 
> packages into multiple sub packages.  Makes things a pain in the ass 
> to what you want/need and makes for fun lock-step dependencies between 
> the subpackages.

That's just because Debian has to do the upstream's work. 

The only charge I can make them here, is that they're working too 
silent instead of making heavy noise in the upstream so that they
actually learn what they're doing wrong. It's like washing a child
day by day and never showing him why it's wise to wash yourself
and how to do it.

Let's take a better example: nmap
This package actually contains two completely different things: 
the portscanner tool and some gtk-based frontend. In fact the "gtk"
useflag switches the second package. 

They're in fact two different applications (just one shipped as
an subdir of another) and so should have two ebuilds.


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

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

[Stephen P. Becker]

> That's just because Debian has to do the upstream's work. 

So if you are so in love with how Debian does everything, why don't you 
just use Debian instead of Gentoo and stop wasting our time with your 
silly rants on how we should do everything just like them.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

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

[W.Kenworthy]

On Mon, 2006-08-07 at 15:48 +0200, Enrico Weigelt wrote:
> * Brian Harring <ferringb@gmail.com> schrieb:

...
> Let's take a better example: nmap
> This package actually contains two completely different things: 
> the portscanner tool and some gtk-based frontend. In fact the "gtk"
> useflag switches the second package. 
> 
> They're in fact two different applications (just one shipped as
> an subdir of another) and so should have two ebuilds.
> 

As a user, please dont do that.  Fragmentation by splitting packages up
is getting ridiculous.  Yes, use a USE flag, but dont make it harder for
users to find, build and install.

My personal opinion is that whilst things like modular X are good for
developers, they are not so good for users - particularly gentoo users.

BillK

-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

On Monday 07 August 2006 21:44, W.Kenworthy wrote:
> My personal opinion is that whilst things like modular X are good for
> developers, they are not so good for users - particularly gentoo users.

we provide meta packages (X/kde/gnome/etc...) for the split packages so users 
can just emerge 1 package to get them all

on one machine i like to run kde so the meta packages are a godsend ... yet on 
another machine, i only want k3b/kmail and nothing else so the split packages 
too are a godsend :)
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

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

[Enrico Weigelt]

* Mike Frysinger <vapier@gentoo.org> schrieb:
> On Monday 07 August 2006 21:44, W.Kenworthy wrote:
> > My personal opinion is that whilst things like modular X are good for
> > developers, they are not so good for users - particularly gentoo users.
> 
> we provide meta packages (X/kde/gnome/etc...) for the split packages 
> so users can just emerge 1 package to get them all
> 
> on one machine i like to run kde so the meta packages are a godsend ... 
> yet on another machine, i only want k3b/kmail and nothing else so the 
> split packages too are a godsend :)

Very good point. 
What's best here is a matter of personal taste or individual
system requirements.

Gentoo's strength comes from respecting those user wishes.
If you stop doing that, you aren't better then all these 
Evil-Binary-Distros (TM) ;-P


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

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

[Donnie Berkholz]

W.Kenworthy wrote:
> My personal opinion is that whilst things like modular X are good for
> developers, they are not so good for users - particularly gentoo users.

Definitely not true. The X.Org 7.1 release shared the vast majority of 
packages with 7.0, so there were very few upgrades -- just a few drivers 
and the server. In the monolithic world, you would've needed to rebuild 
the whole thing for that. Installing it is a one-time cost, upgrading 
goes on forever. And the security updates that already occurred proved 
modularization well worth the effort -- often, just a single package 
(the server) needed an update.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Enrico Weigelt]

* Donnie Berkholz <dberkholz@gentoo.org> schrieb:
> W.Kenworthy wrote:
> >My personal opinion is that whilst things like modular X are good for
> >developers, they are not so good for users - particularly gentoo users.
> 
> Definitely not true. The X.Org 7.1 release shared the vast majority of 
> packages with 7.0, so there were very few upgrades -- just a few drivers 
> and the server. In the monolithic world, you would've needed to rebuild 
> the whole thing for that. Installing it is a one-time cost, upgrading 
> goes on forever. And the security updates that already occurred proved 
> modularization well worth the effort -- often, just a single package 
> (the server) needed an update.

ACK. It's not only an big improvement to maintenability, also 
stops wasting resources.

For example: I've got several headless server systems where I now
have to run some X applications. I only need xlib (and its deps)
on this system, not the whole X distribution. In a monolithic 
world, I would have to install *everything*, from server to tools, 
just for getting some libs.

The modularization is an *huge* improvement. Installations get
smaller and faster and development is much easier.


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

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

[Jan Kundrat]

On Tue, 8 Aug 2006, Enrico Weigelt wrote:
> For example: I've got several headless server systems where I now
> have to run some X applications. I only need xlib (and its deps)
> on this system, not the whole X distribution. In a monolithic 
> world, I would have to install *everything*, from server to tools, 
> just for getting some libs.

Or you could have used the "minimal" USE flag.

Cheers,
-jkt
-- 
gentoo-dev@gentoo.org mailing list

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

[Enrico Weigelt]

* Jan Kundrat <jkt@gentoo.org> schrieb:
> On Tue, 8 Aug 2006, Enrico Weigelt wrote:
> > For example: I've got several headless server systems where I now
> > have to run some X applications. I only need xlib (and its deps)
> > on this system, not the whole X distribution. In a monolithic 
> > world, I would have to install *everything*, from server to tools, 
> > just for getting some libs.
> 
> Or you could have used the "minimal" USE flag.

And what does this flag exactly say at this point ?

Install only xlib ? 
Install xlib and some further ones ? Which ones ?
Install all libs ?


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

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

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Enrico Weigelt wrote:
> * Jan Kundrat <jkt@gentoo.org> schrieb:
>> On Tue, 8 Aug 2006, Enrico Weigelt wrote:
>>> For example: I've got several headless server systems where I now
>>> have to run some X applications. I only need xlib (and its deps)
>>> on this system, not the whole X distribution. In a monolithic 
>>> world, I would have to install *everything*, from server to tools, 
>>> just for getting some libs.
>> Or you could have used the "minimal" USE flag.
> 
> And what does this flag exactly say at this point ?
> 
> Install only xlib ? 
> Install xlib and some further ones ? Which ones ?
> Install all libs ?

Opening an ebuild and reading it must be hard.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Enrico Weigelt]

* Lance Albertson <ramereth@gentoo.org> schrieb:

<snip>

> > And what does this flag exactly say at this point ?
> > 
> > Install only xlib ? 
> > Install xlib and some further ones ? Which ones ?
> > Install all libs ?
> 
> Opening an ebuild and reading it must be hard.

Not what I asked. I'm talking about what an user can expect to get.
You don't expect every user to look trough each ebuilt, seriously ?

And, in case of Xorg, the individual needs may very deeply.
Some applications need just Xlib, some Xaw, others maybe some
extensions, etc.

If you would put evrything in one monolithic package you would,
in the end, need one useflag per library. Or you loose the ability
to build the system for your special needs. Most times you'll get
much, much stuff you won't ever need. Is this compatible with
the gentoo philosphy ?


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

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

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

Enrico Weigelt wrote:
> * Lance Albertson <ramereth@gentoo.org> schrieb:
> 
> <snip>
> 
>>> And what does this flag exactly say at this point ?
>>>
>>> Install only xlib ? 
>>> Install xlib and some further ones ? Which ones ?
>>> Install all libs ?
>> Opening an ebuild and reading it must be hard.
> 
> Not what I asked. I'm talking about what an user can expect to get.
> You don't expect every user to look trough each ebuilt, seriously ?

If you really want to find out what it does? Yes. You can't expect us to
hand hold every user out there. Gentoo isn't meant to be that way. Its a
meta distribution, so you get to choose what you want to do. Just please
don't force the developer community to bend to your needs. If you don't
like that? Then fine, just accept that and please move on.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

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

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Enrico Weigelt wrote:
>> Opening an ebuild and reading it must be hard.
> 
> Not what I asked. I'm talking about what an user can expect to get.
> You don't expect every user to look trough each ebuilt, seriously ?
> 
> And, in case of Xorg, the individual needs may very deeply.
> Some applications need just Xlib, some Xaw, others maybe some
> extensions, etc.
> 
> If you would put evrything in one monolithic package you would,
> in the end, need one useflag per library. Or you loose the ability
> to build the system for your special needs. Most times you'll get
> much, much stuff you won't ever need. Is this compatible with
> the gentoo philosphy ?

Please wake up. We have modular X.org now so just move along and b*tch
about anything else. If you really feel like this is the best thing you
can do for Gentoo development, please provide a procmail rule that kills
all your -dev mails along with relevant replies.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Curtis Napier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Enrico Weigelt wrote:
> * Lance Albertson <ramereth@gentoo.org> schrieb:
> 
> <snip>
> 
>>> And what does this flag exactly say at this point ?
>>>
>>> Install only xlib ? 
>>> Install xlib and some further ones ? Which ones ?
>>> Install all libs ?
>> Opening an ebuild and reading it must be hard.
> 
> Not what I asked. I'm talking about what an user can expect to get.
> You don't expect every user to look trough each ebuilt, seriously ?
> 

Yes, he is completely serious. If you are unwilling to read the
documentation (which includes the actual ebuilds themselves) then you
are going to have a broken system. Nothing any of us can do for you but
keep repeating the same mantra "RTFM".

By the way, Gentoo has a reputation for providing the *BEST*
documentation of any other distro. Many distros actually point their
users to Gentoo docs/forums for answers. Why aren't you utilizing this
awesome resource? Do you know how many man hours we put into those docs?
Every question you have asked so far is already answered in one of our
documentation resources...... Please stop wasting everyones time and do
as we ask - RTFM.

- --Curtis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBRNkAlUb8Q0uRCeTQAQFLqwf/b4Y1zam3UD5X7OUg5qg6/CCyjFAQIDp6
ArqzZt+UL2ZnsTi4hw904lLF6ao0EAFL1z4HQbtK9KtovR6JdgHxAb2cE4dMnZ8z
0Hkc0snISmlha7f/h06+fLjRBUT5KNPJkPzDLToQSL7hLwYVqd31pjCykyC8QcBA
4n1VqaUzz03it3yDCI1LyXPTBb9BQ9J972xWPxmjWyiU4BMSE3HF/EWaTEm1svN6
+D5PzrpUnll7iD4s4DtTongQolBaWiUUGnxdkAbxPE1PD0oQ6g1R/RlW8LvoRuXR
XCB5jN05WWcWUnxYomZGD7JBk+ymPlhREAMg1O/iiNFL//chAgsI4Q==
=I+T+
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Thomas Cort]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On Tue, 8 Aug 2006 16:50:18 +0200
Enrico Weigelt <weigelt@metux.de> wrote:

> * Jan Kundrat <jkt@gentoo.org> schrieb:
> > On Tue, 8 Aug 2006, Enrico Weigelt wrote:
> > > For example: I've got several headless server systems where I now
> > > have to run some X applications. I only need xlib (and its deps)
> > > on this system, not the whole X distribution. In a monolithic 
> > > world, I would have to install *everything*, from server to tools, 
> > > just for getting some libs.
> > 
> > Or you could have used the "minimal" USE flag.
> 
> And what does this flag exactly say at this point ?

$ grep minimal /usr/portage/profiles/use.desc
minimal - Install a very minimal build (disables, for example, plugins,
fonts, most drivers, non-critical features)
 
> Install only xlib ? 
> Install xlib and some further ones ? Which ones ?
> Install all libs ?

Look at the ebuilds and you will find the answer to these questions.

-Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Enrico Weigelt]

* Thomas Cort <tcort@gentoo.org> schrieb:

<snip>

> $ grep minimal /usr/portage/profiles/use.desc
> minimal - Install a very minimal build (disables, for example, plugins,
> fonts, most drivers, non-critical features)

Very vague. 
The user has to take a deep look into the ebuilt and the binary
package to see what's actually inside.

And if you just use this one flag for the whole monolithic 
Xorg tree, you'll loose the ability to install just what's needed.
There has to be an frontline somewhere, and its only *one* line.
So you have to make a decision, where it actually is. 
No matter where you define it, in most situations you will have
to install much much more than really necessary. Either the minimal
variant is too big that it doesn't save much, or it is too small
that you'll need the whole thing.

I think, modularized Xorg, as we have today, is far much better
than the old monolithic thing.


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

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

[Richard Fish]

On 8/8/06, Enrico Weigelt <weigelt@metux.de> wrote:
> I think, modularized Xorg, as we have today, is far much better
> than the old monolithic thing.

I think you are failing to realize that this isn't something that
Gentoo did on it's own.  Upstream went to separate packages, and
Gentoo followed.  Again, this is perfectly in line with "build what
$upstream expects" philosophy.

-Richard
-- 
gentoo-dev@gentoo.org mailing list