[gentoo-dev] preference concerns over "gentoo-ization" of packages

[gentoo-dev] preference concerns over "gentoo-ization" of packages

[Jason Wever]

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

Hi All,

I just wanted to bring up a point and suggest a possible solution for it.

I've noticed that with some of our ebuilds, we have customized the
software it installs beyond fixing broken functionality[1].  Some examples
of this are; default themes for window managers, changes in config files
(changing default parameters and/or chunking up the configs into multiple
files), patches for non-standard functionality, etc[2].

Personally (and I'm guessing I'm not the only one), I'm not big on this
behavior being the default when said packages install.  One of the things
I liked about my pre-Gentoo days when I built my packages from hand is
that nothing was assumed for me, be it dependencies or how a program was
run.  Gentoo for a large part does this.  However there are some ebuilds
that do no do this.  This can be frustrating not only from a
configuration/maintenance point of view, but when trying to troubleshoot
software issues (i.e. bug fixes).  This is a reason we sometimes
have problems dealing with vendors/authors of programs.

I also understand that a lot of people may desire this
additional/customized functionality as well.  Therefore I'd like to
propose the creation of a new keyword that would then allow users to get
this Gentoo customization of their packages should they so choose[3]. 
This makes it still accessible to those who want it, but does not make it
the default behavior.

I think this also falls under what Gentoo wants to present to people

I look forward to hearing your responses to this.

[1] - examples that came to mind at this time are blackbox and derivatives
(particularly in relation to commonbox, which seems unneeded unless you
run more than one of these consistantly), GNU/screen (which adjusts the
default config to remove "dangerous" key bindings)and apache (which
segregates the config into multiple different files).

[2] - For clarification, I'm not opposed to  the pathing of packages when
they are setup, mostly anything that is adjusted after configure has been
run.

[3] - I'm not saying I don't appreciate the work that people have put into
the customization of certain packages, however I don't want to have to
spend time reverting those changes back to something resembling the
default configuration if I don't desire the changes.


Thanks,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1591 bytes --]

On Friday 26 September 2003 22:02, Jason Wever wrote:
> I've noticed that with some of our ebuilds, we have customized the
> software it installs beyond fixing broken functionality[1].  Some examples
> of this are; default themes for window managers, changes in config files
> (changing default parameters and/or chunking up the configs into multiple
> files), patches for non-standard functionality, etc[2].

i like it when config files have examples that are Gentoo specific added onto 
them ... for example, i just finished adding an ebuild/eclass highlighting 
bit of code to the nanorc file for nano ... but i have it commented out so 
users can enable it if they wish ...

> Personally (and I'm guessing I'm not the only one), I'm not big on this
> behavior being the default when said packages install.  One of the things
> I liked about my pre-Gentoo days when I built my packages from hand is
> that nothing was assumed for me, be it dependencies or how a program was
> run.  Gentoo for a large part does this.  However there are some ebuilds
> that do no do this.  This can be frustrating not only from a
> configuration/maintenance point of view, but when trying to troubleshoot
> software issues (i.e. bug fixes).  This is a reason we sometimes
> have problems dealing with vendors/authors of programs.

i agree for the most part but i also think that in some cases life aint this 
great.  going with the apache example, the work web-apps has been putting 
into apache is justified.  plus, it makes bug fixing/testing on our end a lot 
easier.

-mike

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think comments put in stuff is fine. Stuff like config changes, defaults, 
and new features should have a USE flag though, IMO...
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/dQieZl/BHdU+lYMRAv2IAJ9e4s5WeZbIk7JKcaTMSeuNeilQ2gCfdDxO
yEqtJab3hKpcd/fIYwFvsoo=
=76b2
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Aron Griffis]

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

Jason,

I think that much of the config-changing is harmless.  Default themes,
for example, are something that pretty much all the distros change.
It's truly harmless because each individual user has total power to set
their own themes.

Regarding chunking up configs into multiple files, that decision should
be left up to the developers who are maintaining each ebuild.  If the
practice makes any particular packages more difficult to manage, we
should be seeing bugs filed to bring the problem to the attention of the
responsible developers.

Nonetheless, I agree with you in spirit.  Take a look at the comment
near the top of /etc/vim/vimrc for example:

    " The following are some sensible defaults for Vim for most users.
    " We attempt to change as little as possible from Vim's defaults,
    " deviating only where it makes sense

Anyway, I think it really comes down to the decision of the developers
maintaining the ebuilds.  They're the ones in the best situation to
choose whether and how a package should be modified for inclusion into
Gentoo.

Aron

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Jason Wever]

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

On Sat, 27 Sep 2003 22:54:11 -0400
Aron Griffis <agriffis@gentoo.org> wrote:

> Anyway, I think it really comes down to the decision of the developers
> maintaining the ebuilds.  They're the ones in the best situation to
> choose whether and how a package should be modified for inclusion into
> Gentoo.

Well, one of the reasons I brought up this concern comes from
http://www.gentoo.org/main/en/about.xml

In the Larry The Cow poster/image it says;
"He discovered lots of up-to-date packages that could be auto-built using
the optimization settings and build-time functionality that he wanted,
rather than what some distro creator thought would be best for him."

I would assume from this that packages would be installed without
distro customization.   Granted this doesn't say we won't change the
default behavior of programs, but I think it's a logical conclusion based
on the above quote from the website.


-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Troy Dack]

On Sun, 2003-09-28 at 23:08, Jason Wever wrote:
> On Sat, 27 Sep 2003 22:54:11 -0400
> Aron Griffis <agriffis@gentoo.org> wrote:
> 
> > Anyway, I think it really comes down to the decision of the developers
> > maintaining the ebuilds.  They're the ones in the best situation to
> > choose whether and how a package should be modified for inclusion into
> > Gentoo.
> 
> Well, one of the reasons I brought up this concern comes from
> http://www.gentoo.org/main/en/about.xml
> 
> In the Larry The Cow poster/image it says;
> "He discovered lots of up-to-date packages that could be auto-built using
> the optimization settings and build-time functionality that he wanted,
> rather than what some distro creator thought would be best for him."
> 
> I would assume from this that packages would be installed without
> distro customization.   Granted this doesn't say we won't change the
> default behavior of programs, but I think it's a logical conclusion based
> on the above quote from the website.

I can understand where you are coming from.  However I think that since
the Gentoo user base has grown substantially, both in actually numbers
and also in the level of Linux proficiency, I think that it is a good
thing that Gentoo developers are slightly customising the installation
of applications.

Not everybody is a Linux boffin and Gentoo is attracting its fair share
of Linux initiates. Having things configured so that a package works
straight away or so that the configuration doesn't shoot users in the
foot (or have the potential to cause grief for other users) is sensible.

Having said that, those that do wish true customisation can still
perform all of the steps manually using 'ebuild' and set any
configuration options that they wish in that manner.  The flexibility is
still there.

Just my humble opinion.

-- 
Troy Dack		Gentoo moves pretty fast; if you don't stop and
tad@gentoo.org		look around once in awhile, you could miss out.

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4D90BE3C
Key fingerprint = 1F3D 6C15 16AA 09D5 0C96  92E5 FD89 16F9 4D90 BE3C
 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Jason Wever]

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

On Sun, 28 Sep 2003 23:24:20 +1000
Troy Dack <tad@gentoo.org> wrote:

> Not everybody is a Linux boffin and Gentoo is attracting its fair share
> of Linux initiates. Having things configured so that a package works
> straight away or so that the configuration doesn't shoot users in the
> foot (or have the potential to cause grief for other users) is sensible.

That's where a useflag could come in, for situations where devs think it
may be wise to protect users from themselves.  We could then highly
suggest in the installation guides that they make use of it.

-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[foser]

On Sun, 2003-09-28 at 15:41, Jason Wever wrote:
> On Sun, 28 Sep 2003 23:24:20 +1000
> Troy Dack <tad@gentoo.org> wrote:
> 
> > Not everybody is a Linux boffin and Gentoo is attracting its fair share
> > of Linux initiates. Having things configured so that a package works
> > straight away or so that the configuration doesn't shoot users in the
> > foot (or have the potential to cause grief for other users) is sensible.
> 
> That's where a useflag could come in, for situations where devs think it
> may be wise to protect users from themselves.  We could then highly
> suggest in the installation guides that they make use of it.

I don't think USE flags should be used here. One way should be good
enough for all. If you can't justify the changes well enough, they
shouldn't go in. Supporting different ebuild build 'paths' with
consequent different outcomes is not an option in my opinion.

USE flags should be switches to already existing ebuild options, making
them do 'this, that and the other thing' too is confusing and solves
nothing. Clarity and simplicity should be our goals. The transparency of
the process is what made Gentoo attractive, I see that initial goal slip
away more and more.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1917 bytes --]

On Sunday 28 September 2003 15:56, foser wrote:
> On Sun, 2003-09-28 at 15:41, Jason Wever wrote:
>
> I don't think USE flags should be used here. One way should be good
> enough for all. If you can't justify the changes well enough, they
> shouldn't go in. Supporting different ebuild build 'paths' with
> consequent different outcomes is not an option in my opinion.
>
> USE flags should be switches to already existing ebuild options, making
> them do 'this, that and the other thing' too is confusing and solves
> nothing. Clarity and simplicity should be our goals. The transparency of
> the process is what made Gentoo attractive, I see that initial goal slip
> away more and more.

I think that there are many customizations that improve the user experience, 
but that also more or less break the standard. Here I don't mean defaults 
that make the package work out-of-the-box, but for example themes. While I 
like the gentoo theme for gdm, I think there should be a way to say you don't 
what that kind of customization.

I think such a flag should be used in all cases where a customization is 
applied and the following statements apply:
- The package's behaviour, looks or configuration are different from the
  default behaviour and this behaviour was not just enabled by the patch (but
  latent in the package)
- The package does not conform anymore to its documentation. (In this case the
  changes MUST be documented) Except in places like init scripts that are not
  going to work for anything else then redhat.
- Aditional features (not bugfixes) are included by patches for use in some
  ebuilds (like dropshadows for kde). Even if those features are invisible, as
  they break compatibility and possibly cause instability.
- there are probably other cases

Paul

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

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Aron Griffis]

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

Jason Wever wrote:	[Sun Sep 28 2003, 09:08:13AM EDT]
> In the Larry The Cow poster/image it says;
> "He discovered lots of up-to-date packages that could be auto-built using
> the optimization settings and build-time functionality that he wanted,
> rather than what some distro creator thought would be best for him."
> 
> I would assume from this that packages would be installed without
> distro customization.   Granted this doesn't say we won't change the
> default behavior of programs, but I think it's a logical conclusion based
> on the above quote from the website.

I think that is the wrong assumption...

"optimization settings" == compile-time flags, processor setting
"built-time functionality" == libraries, optional modules, gtk vs kde, etc.

Larry's complaint above pertains to things he can't change after the
installation of a package.  Binary-only distros provide you with a
package that is customized with a set of static configure options,
compiled with a set of flags, and linked against libraries that are not
left to the choosing of the user.  That is the problem that Portage
solves by building packages on the user's machine, with USE-flags to
guide the build process.

On the other hand, what you're talking about is run-time functionality.
In general, the changes in the ebuilds modify run-time configuration.
It's not the appropriate place for a USE-flag (in most circumstances)
and furthermore, it's not hard for savvy users to change to their
preferred configuration.  In Gentoo, it has always been up to the
discretion of the responsible devs to choose what default configuration
they feel is appropriate for each individual package.

Aron

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2294 bytes --]

On Sunday 28 September 2003 17:23, Aron Griffis wrote:
> Larry's complaint above pertains to things he can't change after the
> installation of a package.  Binary-only distros provide you with a
> package that is customized with a set of static configure options,
> compiled with a set of flags, and linked against libraries that are not
> left to the choosing of the user.  That is the problem that Portage
> solves by building packages on the user's machine, with USE-flags to
> guide the build process.

many customizations are also allready performed by patches to the sources, not 
only by configuration file changes.

>
> On the other hand, what you're talking about is run-time functionality.
> In general, the changes in the ebuilds modify run-time configuration.
> It's not the appropriate place for a USE-flag (in most circumstances)
> and furthermore, it's not hard for savvy users to change to their
> preferred configuration.  In Gentoo, it has always been up to the
> discretion of the responsible devs to choose what default configuration
> they feel is appropriate for each individual package.

This is allways the case. However look at the following:

When you log out of kde, and you started your system with kdm (kde display 
manager) you get presented a nice dialog with the options to log out, reboot, 
or shutdown. However if you started the system with any other displaymanager, 
such as gdm, you don't get the menu. It would be conceivable that we at a 
point in time added patches to kdm so that it does the same with gdm (which 
provides the capabilities as gnome offers it too, but only for gdm). This is 
nonstandard, but desirable behaviour for most users. In some cases people 
want standard behaviour, for that we have a useflag.

Another thing is the fact that a script of gentoo overwrites the kdm config's 
session variable everytime. This provides consistent and easy behaviour by 
making all installed sessions automatically available, but is not appropriate 
in all cases. There must be a place to turn this behaviour of. Either through 
a USE variable at run time, or through a central configuration variable.

Paul

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

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[foser]

On Sun, 2003-09-28 at 16:26, Paul de Vrieze wrote:
> I think that there are many customizations that improve the user experience, 
> but that also more or less break the standard. Here I don't mean defaults 
> that make the package work out-of-the-box, but for example themes. While I 
> like the gentoo theme for gdm, I think there should be a way to say you don't 
> what that kind of customization.

What is the difference between the Gentoo theme and the default GDM
theme apart from an esthetic preference for one over the other ? Do you
really think that it justifies a USE flag ? The default theme is still
there, so you can easily change. 

Why do you have a problem with the theme while the default package
doesn't even enable the graphical greeter or is that a problem too or is
this just meant to pick a gnome change we once made ? Do you dislike the
splash we used as well, is it really that intrusive ? 

I think you're overdoing this trying to make a point. 

> I think such a flag should be used in all cases where a customization is 
> applied and the following statements apply:
> - The package's behaviour, looks or configuration are different from the
>   default behaviour and this behaviour was not just enabled by the patch (but
>   latent in the package)
> - The package does not conform anymore to its documentation. (In this case the
>   changes MUST be documented) Except in places like init scripts that are not
>   going to work for anything else then redhat.

A package shouldn't be altered so much that it's behaviour changes, that
would be a very bad thing. Distro specific things like you mention
should be solved of course. Uniformity across distros should be a goal,
to reach that i think it's best to follow the upstream package (vanilla)
as close as possible.
 
> - Aditional features (not bugfixes) are included by patches for use in some
>   ebuilds (like dropshadows for kde). Even if those features are invisible, as
>   they break compatibility and possibly cause instability.

In my opinion patches that will not in the foreseeable future make it
into the upstream CVS tree shouldn't be in the Gentoo tree either,
behind a USE flag or not. I cannot comment on kde dropshadow, but a
similar patch for gnome is hackish, plain ugly and unmaintainable by us,
resulting in possible future regressions. But you note yourself that
those sort of patches are of questionable nature, i don't know why you
would want it in the official ebuilds. People who so desperately want it
can easily modify the ebuild themselves to their needs, that's the power
that Gentoo offers. We don't have to hold users by the hand, you learn
to walk by trying and falling down on occasion.

> - there are probably other cases

Now we have different cases that need one flag, but some people might
argue that some special cases need another flag and next thing you know
we have a dozen flags for customizations that are non-intrusive, for
providing mandrake like total rewritten fool-proof config files and what
not.

We need no flag, it is simple : if the change can't be justified for all
users, it shouldn't go in.

And i don't think a little non-intrusive branding needs a flag and i
call it justified as a means of showing one is using the Gentoo distro,
but if you disagree we could maybe drop the GDM theme for the sake of
it. On the other hand you are the first to have a problem with it, most
people really liked it.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Chris Gianelloni]

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

On Sun, 2003-09-28 at 11:23, Aron Griffis wrote:
> I think that is the wrong assumption...
> 
> "optimization settings" == compile-time flags, processor setting
> "built-time functionality" == libraries, optional modules, gtk vs kde, etc.
> 
> Larry's complaint above pertains to things he can't change after the
> installation of a package.  Binary-only distros provide you with a
> package that is customized with a set of static configure options,
> compiled with a set of flags, and linked against libraries that are not
> left to the choosing of the user.  That is the problem that Portage
> solves by building packages on the user's machine, with USE-flags to
> guide the build process.
> 
> On the other hand, what you're talking about is run-time functionality.
> In general, the changes in the ebuilds modify run-time configuration.
> It's not the appropriate place for a USE-flag (in most circumstances)
> and furthermore, it's not hard for savvy users to change to their
> preferred configuration.  In Gentoo, it has always been up to the
> discretion of the responsible devs to choose what default configuration
> they feel is appropriate for each individual package.

I couldn't agree more.  I don't have any problem with having to click
the mouse a few times to change the default theme (using gdm as an
example) away from a Gentoo custom one.  I would have a problem with
functionality being removed completely by default and having to edit an
ebuild or patch manually to re-implement the functionality.

Adding pretty Gentoo backgrounds/themes is completely different from,
say, ripping out the entire Gnome/KDE menu systems and building our own
from scratch.  The former I see no problem with at all.  The latter is
depriving our users of choice and their freedom to have a system the way
they wish, which I feel is opposed to the Gentoo way of doing things
which we all have come to love.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[foser]

On Sun, 2003-09-28 at 17:53, Paul de Vrieze wrote:
> When you log out of kde, and you started your system with kdm (kde display 
> manager) you get presented a nice dialog with the options to log out, reboot, 
> or shutdown. However if you started the system with any other displaymanager, 
> such as gdm, you don't get the menu. It would be conceivable that we at a 
> point in time added patches to kdm so that it does the same with gdm (which 
> provides the capabilities as gnome offers it too, but only for gdm). This is 
> nonstandard, but desirable behaviour for most users. In some cases people 
> want standard behaviour, for that we have a useflag.

Why is this desirable behaviour? I think it's the login managers task to
have these permissions, not a users session. The gnome-session
shutdown/reboot options are nonfunctional for security reasons. I think
the defaults we supply are very sensible, i see no need why we should
alter this. If people like to see this different, it is up to them to
change their configurations accordingly.

> Another thing is the fact that a script of gentoo overwrites the kdm config's 
> session variable everytime. This provides consistent and easy behaviour by 
> making all installed sessions automatically available, but is not appropriate 
> in all cases. There must be a place to turn this behaviour of. Either through 
> a USE variable at run time, or through a central configuration variable.

I don't know why this happens, but if it's really a sensible default
there is no need to have a USE flag. Again the few users that need to
have this another way can easily adapt the ebuild to their needs. 

I can only describe this one way : you think like KDE-ers do. Thats why
it has this overabundance of settings which only works confusing. I know
for the tinkerers out there it's great, but for the general Joe HomeUser
or Jane OfficeAdmin it's pointless. The tinkerers can do the tinkering
themselves, we don't have to hold their hands.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 5273 bytes --]

On Sunday 28 September 2003 18:03, foser wrote:
> What is the difference between the Gentoo theme and the default GDM
> theme apart from an esthetic preference for one over the other ? Do you
> really think that it justifies a USE flag ? The default theme is still
> there, so you can easily change.

That the original is what is original. People want the original, but might not 
know which one is. I think a useflag makes sense as long as it is global, not 
local.

>
> Why do you have a problem with the theme while the default package
> doesn't even enable the graphical greeter or is that a problem too or is
> this just meant to pick a gnome change we once made ? Do you dislike the
> splash we used as well, is it really that intrusive ?
>
Know, I like it, certainly. I actually use it and prefer it over kdm, but 
there are cases where one ones the original packages. If you have ever seen a 
standard redhat 9.0 gnome install you know why. As someone who hardly uses 
gnome I have no clue whatsoever to set that back into the default settings.

> I think you're overdoing this trying to make a point.
>
> > I think such a flag should be used in all cases where a customization is
> > applied and the following statements apply:
> > - The package's behaviour, looks or configuration are different from the
> >   default behaviour and this behaviour was not just enabled by the patch
> > (but latent in the package)
> > - The package does not conform anymore to its documentation. (In this
> > case the changes MUST be documented) Except in places like init scripts
> > that are not going to work for anything else then redhat.
>
> A package shouldn't be altered so much that it's behaviour changes, that
> would be a very bad thing. Distro specific things like you mention
> should be solved of course. Uniformity across distros should be a goal,
> to reach that i think it's best to follow the upstream package (vanilla)
> as close as possible.
>
What is a change in behaviour? While I agree on having things go upstream 
there are cases when the updated behaviour is not available upstream (yet), 
but still desirable in the distribution. In such cases there is the option of 
providing this enhanced behaviour, but allowing users to either enable or 
disable it. An example would be the gentoo menu system. Such a system is so 
interrelated between many applications that it will take a very long time for 
such a thing to be put through upstream that it is viable to do it ourselves. 
It does change behaviour though, and as we offer choice it should be possible 
to not apply the patches to the windowmanager that allow it to happen, even 
if they default to standard behaviour.

> > - Aditional features (not bugfixes) are included by patches for use in
> > some ebuilds (like dropshadows for kde). Even if those features are
> > invisible, as they break compatibility and possibly cause instability.
>
> In my opinion patches that will not in the foreseeable future make it
> into the upstream CVS tree shouldn't be in the Gentoo tree either,
> behind a USE flag or not. I cannot comment on kde dropshadow, but a
> similar patch for gnome is hackish, plain ugly and unmaintainable by us,
> resulting in possible future regressions. But you note yourself that
> those sort of patches are of questionable nature, i don't know why you
> would want it in the official ebuilds. People who so desperately want it
> can easily modify the ebuild themselves to their needs, that's the power
> that Gentoo offers. We don't have to hold users by the hand, you learn
> to walk by trying and falling down on occasion.

Certainly I don't like those questionable patches, however in less havilly 
used packages than kde and gnome there are often patches that greatly enhance 
the behaviour of the package and might make it upstream (however upstream is 
not well maintained), but are stable and valuable enough to allready include 
now instead of waiting another half year for the new version (or go with a 
cvs version)

>
> Now we have different cases that need one flag, but some people might
> argue that some special cases need another flag and next thing you know
> we have a dozen flags for customizations that are non-intrusive, for
> providing mandrake like total rewritten fool-proof config files and what
> not.
>
I think we need a policy, but some packages allready do things that could be 
argued to be not vanilla enough, but still are very valuable. 

> We need no flag, it is simple : if the change can't be justified for all
> users, it shouldn't go in.
>
> And i don't think a little non-intrusive branding needs a flag and i
> call it justified as a means of showing one is using the Gentoo distro,
> but if you disagree we could maybe drop the GDM theme for the sake of
> it. On the other hand you are the first to have a problem with it, most
> people really liked it.
>

I like it, it was an example. I have no problem whith it whatsoever. However, 
gentoo is about choice. That includes the choice not to have patches that do 
more than fix bugs.

Paul

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

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2261 bytes --]

On Sunday 28 September 2003 18:24, foser wrote:
>
> I don't know why this happens, but if it's really a sensible default
> there is no need to have a USE flag. Again the few users that need to
> have this another way can easily adapt the ebuild to their needs.
>
> I can only describe this one way : you think like KDE-ers do. Thats why
> it has this overabundance of settings which only works confusing. I know
> for the tinkerers out there it's great, but for the general Joe HomeUser
> or Jane OfficeAdmin it's pointless. The tinkerers can do the tinkering
> themselves, we don't have to hold their hands.

I think that many of the gentoo users and developers are like me in comming to 
gentoo from running Linux From Scratch. Gentoo is started out as a tinckerers 
distro. It is not gentoo's main point of view to be a distro for linux 
newbees. And indeed, I'm more a kde kind of person than a gnome one. I really 
really dislike the fact that in gnome it is very hard to make it do what YOU 
want, not what the developers wanted. I also really dislike the ok, cancel 
button reversal in gnome. 

I don't think tinkerers need their hands held. However before LFS I ran 
redhat. Do you know how difficult they make it to do any tinkering. Mandrake 
etc. are even worse. I think tinkering should never be inhibited by patches 
from gentoo. I want to be able to read a howto from the LDP and know that as 
long as they don't talk about redhat or any other specific distro, it works 
for me in that way, and that when it doesn't, and I want it to work in that 
way, I can easilly make it work in that way without actually needing to edit 
any ebuild. Editing ebuilds creates a maintenance hell. You either need to 
never update, or edit the new one everytime there is an update.

Further wenn I were to review an application or, say, gnome. I would install 
it, but I would certainly not want any gentoo customizations (I'm reviewing 
gnome, not gentoo). I think there are enough cases for having a vanilla 
useflag. I do agree with you that we don't want dozens of them. For that we 
will get sticky use variables.

Paul

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

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[foser]

On Sun, 2003-09-28 at 20:14, Paul de Vrieze wrote:
> That the original is what is original. People want the original, but might not 
> know which one is. I think a useflag makes sense as long as it is global, not 
> local.

Well, actually there is not one original. GDM comes with two themes
vanilla, we add one. The choice of one over the other is an esthetical
one. And as said, by default the graphical greeter is disabled, so the
discussion should not be focused on what theme we provide by default,
but if we should enable the graphical greeter by default or not.

> > Why do you have a problem with the theme while the default package
> > doesn't even enable the graphical greeter or is that a problem too or is
> > this just meant to pick a gnome change we once made ? Do you dislike the
> > splash we used as well, is it really that intrusive ?
> >
> Know, I like it, certainly. I actually use it and prefer it over kdm, but 
> there are cases where one ones the original packages. If you have ever seen a 
> standard redhat 9.0 gnome install you know why. As someone who hardly uses 
> gnome I have no clue whatsoever to set that back into the default settings.

We are not RedHat, we don't do that. I see these changes as
non-intrusive, if someone disagrees and has a good point about it I'm
willing to remove them. But in this case i don't think someone would
prefer one of the default themes over the Gentoo theme. A lot of people
seem to like a little branding, have you ever thought about our
'default' grub splash ? Do you think that would need a USE flag too ? I
would not easily make changes that go beyond these and are not easily
adaptable. You can shutdown from GDM, then you know how to configure it
: it's in the same menu.

> What is a change in behaviour? While I agree on having things go upstream 
> there are cases when the updated behaviour is not available upstream (yet), 
> but still desirable in the distribution. In such cases there is the option of 
> providing this enhanced behaviour, but allowing users to either enable or 
> disable it.
>  An example would be the gentoo menu system. Such a system is so 
> interrelated between many applications that it will take a very long time for 
> such a thing to be put through upstream that it is viable to do it ourselves. 
> It does change behaviour though, and as we offer choice it should be possible 
> to not apply the patches to the windowmanager that allow it to happen, even 
> if they default to standard behaviour.

Let's not go into individual cases, there's always the odd one out. But
the Gentoo menu system in it's _proposed_ implementation would need it's
own flag, not some general flag. So that's 2 flags for non-default
behaviour already, good start, let's add some more.

If the final proposed menu implementation is good enough (and i think it
can be although not in it's current form) then i even doubt it would
need a USE flag. Again transparency : the menu system should blend in so
well the difference between having it and not having it is negligible.

> Certainly I don't like those questionable patches, however in less havilly 
> used packages than kde and gnome there are often patches that greatly enhance 
> the behaviour of the package and might make it upstream (however upstream is 
> not well maintained), but are stable and valuable enough to allready include 
> now instead of waiting another half year for the new version (or go with a 
> cvs version)

This is what i mean with the blurb about go into upstream CVS in the
foreseeable future. To stay with the examples we used : the gnome
dropshadow patch will not make it into CVS as it is, if ever. Certainly
not as long there's no proper X support for features like transparency.

Useful patches can go in, but something which won't make it in and is
unmaintainable on our side should not go in. If i start adding all sorts
of fancy patches here and there i really sound would have regression
with breaking patches i can't repair. This is partially due to how
Gentoo is managed, relatively few developers and a lot of packages. Not
like eg. Debian where every package has often one (or more) dedicated
maintainer(s) or Redhat where they have people work fulltime, so being
able to do much more work on packages.

It's the herds lead/developers that should assess what patch is viable
to have in and what not, that comes down to common sense. But i think we
should be very careful with adding intrusive patches which change
behaviour considerably.

> > Now we have different cases that need one flag, but some people might
> > argue that some special cases need another flag and next thing you know
> > we have a dozen flags for customizations that are non-intrusive, for
> > providing mandrake like total rewritten fool-proof config files and what
> > not.
> >
> I think we need a policy, but some packages allready do things that could be 
> argued to be not vanilla enough, but still are very valuable. 

Policy here, policy there. Policy is all good, but in the end it comes
down to a bit of common sense. I know some developers feel more
confident with a few (or a lot) written down rules backing them up, I
just argue a case over with myself and a few other (involved) devs if
needed. I can justify the things i do to myself and if someone disagrees
they can discuss it with me and we can work it out. I can of course be
wrong at times, but that's human. 

If packages do things that can be argued, then they should be argued.
Mistakes made in the past can be corrected, that's not a reason to make
a policy for these cases.

> > We need no flag, it is simple : if the change can't be justified for all
> > users, it shouldn't go in.
> >
> > And i don't think a little non-intrusive branding needs a flag and i
> > call it justified as a means of showing one is using the Gentoo distro,
> > but if you disagree we could maybe drop the GDM theme for the sake of
> > it. On the other hand you are the first to have a problem with it, most
> > people really liked it.
> >
> 
> I like it, it was an example. I have no problem whith it whatsoever. However, 
> gentoo is about choice. That includes the choice not to have patches that do 
> more than fix bugs.

I think Gentoo is about power, power to have a distribution without
fuzz, packages as upstream developers intended them to be. The power of
Gentoo lies in the ease way you can adapt it to your needs. Ebuilds are
not black magic, whoever needs to manipulate them can do so.

I keep repeating myself here, but i really think holding hands like some
other distros do is not needed. The defaults should be good enough for
the majority of users, the ones who need more (and know so) i deem smart
enough to manipulate ebuilds to their needs. Holding hands is insulting
the intelligence of our users.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[foser]

On Sun, 2003-09-28 at 20:32, Paul de Vrieze wrote:
> I think that many of the gentoo users and developers are like me in comming to 
> gentoo from running Linux From Scratch. Gentoo is started out as a tinckerers 
> distro. It is not gentoo's main point of view to be a distro for linux 
> newbees.

Well, that's what you do by holding hands for every possible extra and
what not. As if power users themselves cannot adapt it to their needs.

>  And indeed, I'm more a kde kind of person than a gnome one. I really 
> really dislike the fact that in gnome it is very hard to make it do what YOU 
> want, not what the developers wanted.

GNOME as it is is not meant to be tinkered with, it's meant to be worked
with and people seem to enjoy it's simplicity. Yes it's a choice, but i
think it's a good one. Sensible defaults all the way.

>  I also really dislike the ok, cancel 
> button reversal in gnome. 

And i don't like .. uh oh, yeah well let's get into such a thread. 'It
has always been done this way' is not the way improvements happen.

> I don't think tinkerers need their hands held. However before LFS I ran 
> redhat. Do you know how difficult they make it to do any tinkering. Mandrake 
> etc. are even worse. I think tinkering should never be inhibited by patches 
> from gentoo.

Yeah, so let's ditch the patches and extras. The tinkerers know how to
apply them.

>  I want to be able to read a howto from the LDP and know that as 
> long as they don't talk about redhat or any other specific distro, it works 
> for me in that way, and that when it doesn't, and I want it to work in that 
> way, I can easilly make it work in that way without actually needing to edit 
> any ebuild. Editing ebuilds creates a maintenance hell. You either need to 
> never update, or edit the new one everytime there is an update.

Currently maybe, although if our needs be so we could probably add
portage support for local changes (beyond a local tree). Attack the
problem at it's root, not at it's leaves. We're getting into details
here, where the discussion goes from an ideological level (this is how i
see the distro) to implementation details (well i don't like it because
currently it works this way). 

Moving away from vanilla for some users (USE dependant or not) will have
a group of users have the described problems. 'You should have used the
vanilla USE flag.' is not a proper response then, how should they know 
is the default Gentoo not good enough ?

> Further wenn I were to review an application or, say, gnome. I would install 
> it, but I would certainly not want any gentoo customizations (I'm reviewing 
> gnome, not gentoo). I think there are enough cases for having a vanilla 
> useflag. I do agree with you that we don't want dozens of them. For that we 
> will get sticky use variables.

Well, Gentoo customizations in GNOME do not go much further than the GDM
theme I'm afraid and that could be discussed if you really disagree
there (but i know you don't ;)).

In one way you try to promote tinkering, only the distro has to make it
easy for the tinkerers. On the other hand you want Gentoo to stay
vanilla as well. I see this as a conflict. Tinkerers are not the ones
who need it to be available the easy way, the ones who do not want to 
tinker are not interested in having it available in an easy way.

For me it's not about Gentoo being vanilla all the way, but for Gentoo
to be as vanilla as possible with only the really needed extras added.
Not the not-so-needed extras added behind some USE flag and some other
cool gadgets behind another USE flag.

- foser



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Nate Duehr]

On Fri, Sep 26, 2003 at 10:02:21PM -0400, Jason Wever wrote:
> Hi All,
> 
> I just wanted to bring up a point and suggest a possible solution for it.
> 
> I've noticed that with some of our ebuilds, we have customized the
> software it installs beyond fixing broken functionality[1].  Some examples
> of this are; default themes for window managers, changes in config files
> (changing default parameters and/or chunking up the configs into multiple
> files), patches for non-standard functionality, etc[2].

<snip>

I am not a developer, but I was mildly surprised and pleased that MTA's
on Gentoo "understand" what other packages are installed and get
configured appropriately -- example, qmail will act differently if the
qmail-queue (is that the right name?) and a virus scanner are
installed...

In other words, "it just works". 

I don't know if this type of customization is the type of thing you guys
are discussing, but a default qmail build certainly has to be configured
quite differently to get features like this to work from "raw source"
builds. 

Personally I like that Gentoo's package maintainers for tools like this
made my life a little easier in this sense, but if you're going for a
more "pure" source-only distro, you'd have to drop things like this as
well.

-- 
Nate Duehr <nate@natetech.com>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Luke-Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 28 September 2003 09:42 pm, Nate Duehr wrote:
> I don't know if this type of customization is the type of thing you guys
> are discussing
I think the discussion is about ebuilds which add features (a non-current 
bittorrent ebuild adds a peer-display thing) or change art (such as changing 
KDE/GNOME to have Gentoo icons, perhaps). Things which do not change the 
software's actual functionality should be fine on any system...
- -- 
Luke-Jr
Developer, Gentoo Linux
http://www.gentoo.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/d1wwZl/BHdU+lYMRAoZ4AJ9op+6L1vobFzRtVcdWFgWLKkeH8wCgjFfr
qktZneNT6/ABNotb4c50aS8=
=cdei
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Tom Wesley]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2880 bytes --]

On Sunday 28 September 2003 16:53, Paul de Vrieze wrote:
> On Sunday 28 September 2003 17:23, Aron Griffis wrote:
> > Larry's complaint above pertains to things he can't change after the
> > installation of a package.  Binary-only distros provide you with a
> > package that is customized with a set of static configure options,
> > compiled with a set of flags, and linked against libraries that are not
> > left to the choosing of the user.  That is the problem that Portage
> > solves by building packages on the user's machine, with USE-flags to
> > guide the build process.
>
> many customizations are also allready performed by patches to the sources,
> not only by configuration file changes.
>
> > On the other hand, what you're talking about is run-time functionality.
> > In general, the changes in the ebuilds modify run-time configuration.
> > It's not the appropriate place for a USE-flag (in most circumstances)
> > and furthermore, it's not hard for savvy users to change to their
> > preferred configuration.  In Gentoo, it has always been up to the
> > discretion of the responsible devs to choose what default configuration
> > they feel is appropriate for each individual package.
>
> This is allways the case. However look at the following:
>
> When you log out of kde, and you started your system with kdm (kde display
> manager) you get presented a nice dialog with the options to log out,
> reboot, or shutdown. However if you started the system with any other
> displaymanager, such as gdm, you don't get the menu. It would be
> conceivable that we at a point in time added patches to kdm so that it does
> the same with gdm (which provides the capabilities as gnome offers it too,
> but only for gdm). This is nonstandard, but desirable behaviour for most
> users. In some cases people want standard behaviour, for that we have a
> useflag.
>

Should this not be patched upstream, and only included in Gentoo as an option 
(use-flags or such) until such time as included in main source?

> Another thing is the fact that a script of gentoo overwrites the kdm
> config's session variable everytime. This provides consistent and easy
> behaviour by making all installed sessions automatically available, but is
> not appropriate in all cases. There must be a place to turn this behaviour
> of. Either through a USE variable at run time, or through a central
> configuration variable.

This is overall and outside the scope of any single package, is it not?  At 
present no KDM attempts to find Gnome, XFCE and the like, and relies on 
configuration files.  Perhaps this too should be submitted upstream to allow 
KDM, GDM, XDM, elogin etc to perform this task?  Given the large amount of 
login managers in that list alone, perhaps it should be pushed sideways to 
some external package?

-- 
Tom Wesley

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

Re: [gentoo-dev] preference concerns over "gentoo-ization" of packages

[Toby Dickenson]

On Sunday 28 September 2003 23:37, Tom Wesley wrote:
> On Sunday 28 September 2003 16:53, Paul de Vrieze wrote:
> > When you log out of kde, and you started your system with kdm (kde
> > display manager) you get presented a nice dialog with the options to log
> > out, reboot, or shutdown. However if you started the system with any
> > other displaymanager, such as gdm, you don't get the menu. It would be
> > conceivable that we at a point in time added patches to kdm so that it
> > does the same with gdm (which provides the capabilities as gnome offers
> > it too, but only for gdm).
>
> Should this not be patched upstream, and only included in Gentoo as an
> option (use-flags or such) until such time as included in main source?

This policy was the number one main reason that first attracted me to Gentoo. 
Surely this policy has been an important part of Gentoo since its beginnings 
(See 'Rant' on http://www-106.ibm.com/developerworks/library/l-dist2.html). 
Recently the Gentoo-Hardened team in particular have been aggressive in 
pushing their changes upstream.

I wouldnt want to see this change.

-- 
Toby Dickenson


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over "gentoo-ization" ofpackages

[Paul de Vrieze]

>
> In one way you try to promote tinkering, only the distro has to make it
> easy for the tinkerers. On the other hand you want Gentoo to stay
> vanilla as well. I see this as a conflict. Tinkerers are not the ones
> who need it to be available the easy way, the ones who do not want to
> tinker are not interested in having it available in an easy way.

Tinkering now is inconvenient. If you know a different way to do it which
is not by a useflag I think that is acceptable too. I don't think it needs
to be easy to be non-default, but now it is in my opinion really hard.

>
> For me it's not about Gentoo being vanilla all the way, but for Gentoo
> to be as vanilla as possible with only the really needed extras added.

I think that should be the default too. I want to argue that in cases we
might have a useflag to allow people to disable the as vanilla as possible
and go with fully vanilla with only bugfixes. As I don't think this kind
of useflag should be the default in any case I think one useflag should be
enough.

> Not the not-so-needed extras added behind some USE flag and some other
> cool gadgets behind another USE flag.

I'm not in favor of all kinds of cool gadgets and many not-so-needed
extras. I don't mean to say I want dropshadows in kde or gnome.

Paul

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] preference concerns over

[Paul de Vrieze]

>
> I am not a developer, but I was mildly surprised and pleased that MTA's
> on Gentoo "understand" what other packages are installed and get
> configured appropriately -- example, qmail will act differently if the
> qmail-queue (is that the right name?) and a virus scanner are
> installed...
>
> In other words, "it just works".
>
> I don't know if this type of customization is the type of thing you guys
> are discussing, but a default qmail build certainly has to be configured
> quite differently to get features like this to work from "raw source"
> builds.

This is one of the things I think we are discussing. Some people don't
like this for certain reasons. I think we should accomodate those people
by allowing them to turn this of without them needing to edit the ebuild
or interfering with the build process.

>
> Personally I like that Gentoo's package maintainers for tools like this
> made my life a little easier in this sense, but if you're going for a
> more "pure" source-only distro, you'd have to drop things like this as
> well.
>

I want to accomodate both. I personally like the choices made by the
gentoo developers, but I think there are people who don't or are
principally against things being non-vanilla, and we might accomodate
them.

Paul


--
gentoo-dev@gentoo.org mailing list