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

[Paul de Vrieze]

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@g.o
Homepage: http://www.devrieze.net