[gentoo-dev] addition of optional dependencies to (gtk+-2.4.1)

[gentoo-dev] addition of optional dependencies to (gtk+-2.4.1)

[Eric Brown]

I'll be as terse as possible with this:

gtk+-2.4.1 has an added dependency (gnome-icon-theme) that is not apparently 
a dependency for gtk+ (according to the INSTALL file in the gtk tarball).  
Like many others, I like to keep my system clean, so I don't necessarily 
think I should be forced to install that dependency when I update GTK.

I have already suggested that we add a local use flag for this feature, but 
I have met with stern opposition from khai.  Since adding the use flag for 
this is such a small modification, and because this isn't the first time 
I've seen unwanted packages added as strict dependencies, I would like to 
propose that someone help us fix this problem.

I know ebuilds are not perfect, but I think if we have the chance to give 
users added flexibility here, we should.  To me, the argument that this is 
not "bloat" because it doesn't take up much space is not relevant because 
space isn't the real issue; it's choice.

Are there any proposals on how to approach this problem?  I think it may 
even be a whole class of problems that need to be considered.

--Eric

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.com/go/onm00200415ave/direct/01/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] addition of optional dependencies to (gtk+-2.4.1)

[foser]

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

On Mon, 2004-05-10 at 22:29 -0400, Eric Brown wrote:
> I'll be as terse as possible with this:
> 
> gtk+-2.4.1 has an added dependency (gnome-icon-theme) that is not apparently 
> a dependency for gtk+ (according to the INSTALL file in the gtk tarball).
> Like many others, I like to keep my system clean, so I don't necessarily 
> think I should be forced to install that dependency when I update GTK.

As said in the bugs concerning this, we try to have a usable default
setup. The filechooser as it is, is not usable without icons.

> I have already suggested that we add a local use flag for this feature, but 
> I have met with stern opposition from khai.  Since adding the use flag for 
> this is such a small modification, and because this isn't the first time 
> I've seen unwanted packages added as strict dependencies, I would like to 
> propose that someone help us fix this problem.

Don't blame the messenger. I was the one who added these deps, khai only
did the sane thing by invalidating the bug for the simple fact that it
is not a bug. It's not an optional gnome dep (gnome comes by default
with it), it's a gtk dep. That rules out the USE flag. The difference
gtk/gnome is diminishing, so just see it as one more step towards
integration.
Anyway, the main problem with the bug was that the way in which it was
written lacked a certain maturity, that doesn't help making your point.
I must say khai handled that pretty well, I can tell you that I would've
probably been a whole lot less polite.
I propose you look at the real issue here and why this dep got added and
then if you still think you have point you could try the ombudsman to
mediate (plasmaroo?).

> I know ebuilds are not perfect, but I think if we have the chance to give 
> users added flexibility here, we should.  To me, the argument that this is 
> not "bloat" because it doesn't take up much space is not relevant because 
> space isn't the real issue; it's choice.

It's no choice. We don't give a choice for 'non-working/non-usable'
systems : USE="idontwantthistowork". We create ebuilds that should work
by default in all situations. I can only say that this is the case now,
before that the ebuild lacked.
It amuses me that people only seem to complain about the dep which
contains 'gnome' in it's name. The changes imply more deps that are more
intrusive, but nobody has even mentioned them. But I wasn't expecting
anything else when adding it, to me it proves the shallowness of this
whole argument.

> Are there any proposals on how to approach this problem?  I think it may 
> even be a whole class of problems that need to be considered.

Well actually in one of the bugs I gave a possible alternate approach on
how to get rid of these deps, maybe you could try to be more
constructive and solve this problem in a way that is satisfying to all
parties involved.
We have good reasons to add these deps, you have none and are obviously
offended by the fact that you have a gnome package now.

- foser

PS. related bugs
http://bugs.gentoo.org/show_bug.cgi?id=50085
http://bugs.gentoo.org/show_bug.cgi?id=50498

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

Re: [gentoo-dev] addition of optional dependencies to (gtk+-2.4.1)

[Eric Brown]

So you're saying that GTK itself actually needs gnome-icon-theme to be 
usable?  If this is the case I'll just kindly ask that the GTK devs update 
the INSTALL docs to mention this new dependency.  If it's really just a kind 
of evolution for GTK, then I have no complaints.

Given that it's a dep, could someone point me to a GTK app that will not 
work properly if gnome-icon-theme is not installed?  I will probably need at 
least 1 example of this in order to make my case to the GTK devs.  Thanks.

--Eric

>
>On Mon, 2004-05-10 at 22:29 -0400, Eric Brown wrote:
> > I'll be as terse as possible with this:
> >
> > gtk+-2.4.1 has an added dependency (gnome-icon-theme) that is not 
>apparently
> > a dependency for gtk+ (according to the INSTALL file in the gtk 
>tarball).
> > Like many others, I like to keep my system clean, so I don't necessarily
> > think I should be forced to install that dependency when I update GTK.
>
>As said in the bugs concerning this, we try to have a usable default
>setup. The filechooser as it is, is not usable without icons.
>
> > I have already suggested that we add a local use flag for this feature, 
>but
> > I have met with stern opposition from khai.  Since adding the use flag 
>for
> > this is such a small modification, and because this isn't the first time
> > I've seen unwanted packages added as strict dependencies, I would like 
>to
> > propose that someone help us fix this problem.
>
>Don't blame the messenger. I was the one who added these deps, khai only
>did the sane thing by invalidating the bug for the simple fact that it
>is not a bug. It's not an optional gnome dep (gnome comes by default
>with it), it's a gtk dep. That rules out the USE flag. The difference
>gtk/gnome is diminishing, so just see it as one more step towards
>integration.
>Anyway, the main problem with the bug was that the way in which it was
>written lacked a certain maturity, that doesn't help making your point.
>I must say khai handled that pretty well, I can tell you that I would've
>probably been a whole lot less polite.
>I propose you look at the real issue here and why this dep got added and
>then if you still think you have point you could try the ombudsman to
>mediate (plasmaroo?).
>
> > I know ebuilds are not perfect, but I think if we have the chance to 
>give
> > users added flexibility here, we should.  To me, the argument that this 
>is
> > not "bloat" because it doesn't take up much space is not relevant 
>because
> > space isn't the real issue; it's choice.
>
>It's no choice. We don't give a choice for 'non-working/non-usable'
>systems : USE="idontwantthistowork". We create ebuilds that should work
>by default in all situations. I can only say that this is the case now,
>before that the ebuild lacked.
>It amuses me that people only seem to complain about the dep which
>contains 'gnome' in it's name. The changes imply more deps that are more
>intrusive, but nobody has even mentioned them. But I wasn't expecting
>anything else when adding it, to me it proves the shallowness of this
>whole argument.
>
> > Are there any proposals on how to approach this problem?  I think it may
> > even be a whole class of problems that need to be considered.
>
>Well actually in one of the bugs I gave a possible alternate approach on
>how to get rid of these deps, maybe you could try to be more
>constructive and solve this problem in a way that is satisfying to all
>parties involved.
>We have good reasons to add these deps, you have none and are obviously
>offended by the fact that you have a gnome package now.
>
>- foser
>
>PS. related bugs
>http://bugs.gentoo.org/show_bug.cgi?id=50085
>http://bugs.gentoo.org/show_bug.cgi?id=50498
><< signature.asc >>

_________________________________________________________________
Express yourself with the new version of MSN Messenger! Download today - 
it's FREE! http://messenger.msn.com/go/onm00200471ave/direct/01/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] addition of optional dependencies to (gtk+-2.4.1)

[cbrewer]

 
 
On Tuesday May 11 2004 5:08, foser wrote: 
 
> Well actually in one of the bugs I gave a possible alternate approach on 
> how to get rid of these deps, maybe you could try to be more 
> constructive and solve this problem in a way that is satisfying to all 
> parties involved. 
> We have good reasons to add these deps, you have none and are obviously 
> offended by the fact that you have a gnome package now. 
> 
> - foser 
> 
> PS. related bugs 
> http://bugs.gentoo.org/show_bug.cgi?id=50085 
> http://bugs.gentoo.org/show_bug.cgi?id=50498 
 
I don't think it's about gnome or not gnome myself. I have a concern that this 
is three extra deps for something I'll probably never see. From the hot 
tempers on both sides over this, it almost sounds like you're happy to give 
out a gnome dep for spite, although I'm sure that's not the case, though 
casual observance makes me wonder. I think had this been non-gnome/kde issue 
it would have never had the deps applied, and properly been marked upstream, 
as its a fault in gtk+ packaging for not providing the support for its file 
chooser. 
--  
Chuck Brewer 
Registered Linux User #284015 
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred. 
 

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] addition of optional dependencies to (gtk+-2.4.1)

[Alastair Tse]

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


On 11 May 2004, at 18:44, Eric Brown wrote:

> So you're saying that GTK itself actually needs gnome-icon-theme to be 
> usable?  If this is the case I'll just kindly ask that the GTK devs 
> update the INSTALL docs to mention this new dependency.  If it's 
> really just a kind of evolution for GTK, then I have no complaints.

Anyway, icons are needed for the new GTK+ 2.4 file chooser at the very 
least. Look in gtk/gtkfilesystemunix.c. There are gnome icon names in 
there. Yes, GTK+ works without those icons, but it'll just look ugly 
and un-usable.

If you want a bare-minimum system, then you can inject packages all you 
like, thats the beauty of Gentoo. But we're here to provide some sane 
defaults, and providing icons with a GUI toolkit is a sane default 
here.

Cheers,
- --
Alastair 'liquidx' Tse
  >> Gentoo Developer (Python/GNOME/CJK/PDA/Bluetooth)
  >> http://www.liquidx.net/ | http://dev.gentoo.org/~liquidx/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAoeoAOM4cezkHFPYRAg1EAKCz3PL3cvdmVdmhkTn5Z0BXkRqVHwCZAa1y
RLsBTxCMksKQbzEGmzMC/dM=
=/U2B
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] addition of optional dependencies to (gtk+-2.4.1)

[foser]

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

On Tue, 2004-05-11 at 21:01 -0400, cbrewer@stealthaccess.net wrote:
>   
> On Tuesday May 11 2004 5:08, foser wrote: 
>  
> > Well actually in one of the bugs I gave a possible alternate approach on 
> > how to get rid of these deps, maybe you could try to be more 
> > constructive and solve this problem in a way that is satisfying to all 
> > parties involved. 
> > We have good reasons to add these deps, you have none and are obviously 
> > offended by the fact that you have a gnome package now. 
> > 
> > - foser 
> > 
> > PS. related bugs 
> > http://bugs.gentoo.org/show_bug.cgi?id=50085 
> > http://bugs.gentoo.org/show_bug.cgi?id=50498 
> 
> I don't think it's about gnome or not gnome myself. I have a concern that this 
> is three extra deps for something I'll probably never see. 

This is the first time someone mentiones more than 1 dep (i only heard
about the icon-theme so far - i did mention i found that amusing didn't
i ?). It's probably 4 extra deps btw (off the top of my head).
And why won't you see it ? The old fileselector API is now deprecated,
all GTK+ apps will move to the new API eventually. You will see it and
you will need these deps, especially if you are only a gtk+ user (not
gnome), because this fixes a usability problem for plain gtk+ user, not
gnome users.

> From the hot 
> tempers on both sides over this, it almost sounds like you're happy to give 
> out a gnome dep for spite, although I'm sure that's not the case, though 
> casual observance makes me wonder.

It's just a set of icon themes based on the fdo specs, that it happens
to have gnome in it's package name is pretty irrelevant. I only expected
nothing else than baseless criticism on this and my gut feeling was
right. It has only been an issue about a 'gnome dep', even you make it
into that. It even got mentioned earlier that it was _not_ the size that
was a problem, that would at least make for a bit of a reasonable
argument. I really don't see what it is about than a petty naming issue.
And it's the way this has been brought up so far that makes us touchy,
like we're idiots here for adding these deps.

>  I think had this been non-gnome/kde issue 
> it would have never had the deps applied, and properly been marked upstream, 
> as its a fault in gtk+ packaging for not providing the support for its file 
> chooser. 

I don't go mark things upstream that can easily be fixed here and now.
Anyway, this is just plain part of gtk+ now, they only forgot to mention
it as explicit deps. There may be less intrusive ways possibly, but I
don't know if it's worth the effort. Anyway, i've not heard back from
anyone willing to implement it in another way.

- foser

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