Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 420569 - x11-themes/light-themes makes use of gtk3 useflag
Summary: x11-themes/light-themes makes use of gtk3 useflag
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Low minor (vote)
Assignee: Sebastian Pipping
URL: http://devmanual.gentoo.org/general-c...
Whiteboard:
Keywords:
Depends on:
Blocks: use_gtk3
  Show dependency tree
 
Reported: 2012-06-10 18:23 UTC by Julian Ospald
Modified: 2014-04-04 18:12 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Ospald 2012-06-10 18:23:41 UTC
These packages make use of gtk3 useflag which indicates that there are issues of migration to gtk+:3.
Gtk3 and similar useflags should be avoided.

Adding to tracker. Please have a look.

On top of that, it is in this case a bogus useflag, cause it does nothing except pulling in a dependency.
Comment 1 Sebastian Pipping gentoo-dev 2012-06-10 18:30:38 UTC
Hey there,


we'll need your help with this.


(In reply to comment #0)
> These packages make use of gtk3 useflag which indicates that there are
> issues of migration to gtk+:3.

None that I know of.


> Gtk3 and similar useflags should be avoided.
> 
> Adding to tracker. Please have a look.
> 
> On top of that, it is in this case a bogus useflag, cause it does nothing
> except pulling in a dependency.

I wouldn't call it bogus.  The listed runtime dependency is needed in case of gtk3 and that only.  What better way is there to go?  I don't see anything in the tracker bug that I could make use of with this package.
Comment 2 Julian Ospald 2012-06-10 18:34:53 UTC
drop the useflag and mention it as optional runtime dependency in an elog in pkg_postinst

Useflags are not meant to _just_ pull in runtime dependencies. If I disable that useflag, but have that package installed, it does nothing.
Comment 3 Sebastian Pipping gentoo-dev 2012-06-10 18:39:43 UTC
(In reply to comment #2)
> drop the useflag and mention it as optional runtime dependency in an elog in
> pkg_postinst
> 
> Useflags are not meant to _just_ pull in runtime dependencies. If I disable
> that useflag, but have that package installed, it does nothing.

I am aware of problems with this approach.
However, besides people sharing thoughts about this on Planet Gentoo I am not aware of a decision or solution with regard to that matter.

Please provide the source of the documented policy that you refer to.
Comment 4 Julian Ospald 2012-06-10 18:40:40 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > drop the useflag and mention it as optional runtime dependency in an elog in
> > pkg_postinst
> > 
> > Useflags are not meant to _just_ pull in runtime dependencies. If I disable
> > that useflag, but have that package installed, it does nothing.
> 
> I am aware of problems with this approach.
> However, besides people sharing thoughts about this on Planet Gentoo I am
> not aware of a decision or solution with regard to that matter.
> 
> Please provide the source of the documented policy that you refer to.

http://devmanual.gentoo.org/general-concepts/use-flags/index.html
Comment 5 Sebastian Pipping gentoo-dev 2012-06-10 18:41:20 UTC
(In reply to comment #3)
> > drop the useflag and mention it as optional runtime dependency in an elog in
> > pkg_postinst

PS: And just dropping the use flag doesn't improve anything in my opinion.
Comment 6 Julian Ospald 2012-06-10 18:42:56 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > > drop the useflag and mention it as optional runtime dependency in an elog in
> > > pkg_postinst
> 
> PS: And just dropping the use flag doesn't improve anything in my opinion.

It removes a bogus useflag, so people can rely on useflags being switches.
Comment 7 Sebastian Pipping gentoo-dev 2012-06-10 18:54:50 UTC
(In reply to comment #6)
> > PS: And just dropping the use flag doesn't improve anything in my opinion.
> 
> It removes a bogus useflag, so people can rely on useflags being switches.

Would you stop calling my prior work "bogus", please?

We agree that the flag actually does something and we disagree if the outcome is more valueable than its harm or the other way around, that's all.


(In reply to comment #4)
> http://devmanual.gentoo.org/general-concepts/use-flags/index.html

I guess you refer to

"The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed."

which seems to be of 2010 already:

http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commitdiff;h=8095994ddde25a75e99fd34dff81cf8522cd0ce4

Interesting.  I see the point for certain other cases (e.g. layman[git]) but:

I am unsure why to make a distinction between "fail to be usable" for a C program and "fail to be usable" for another kind of language or data.  I do not want to continue, before we have an answer to that.
Comment 8 Julian Ospald 2012-06-10 19:07:29 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > > PS: And just dropping the use flag doesn't improve anything in my opinion.
> > 
> > It removes a bogus useflag, so people can rely on useflags being switches.
> 
> Would you stop calling my prior work "bogus", please?

Sry, didn't know that word is offensive. I'm just trying to clean up the gtk2/3 situation a bit.

> 
> We agree that the flag actually does something

It _eventually_ does something. It should always do something.

> 
> (In reply to comment #4)
> > http://devmanual.gentoo.org/general-concepts/use-flags/index.html
> 
> I guess you refer to
> 
> "The usage of a USE flag should not control runtime dependencies when the
> package does not link to it. Doing so will create extra configuration for
> the package and re-compilation for no underlying file change on disk. This
> should be avoided and instead can be conveyed to the user via post install
> messages if needed."
> 
> which seems to be of 2010 already:
> 
> http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commitdiff;
> h=8095994ddde25a75e99fd34dff81cf8522cd0ce4
> 
> Interesting.  I see the point for certain other cases (e.g. layman[git]) but:
> 
> I am unsure why to make a distinction between "fail to be usable" for a C
> program and "fail to be usable" for another kind of language or data.  I do
> not want to continue, before we have an answer to that.

Yes, I consider that explanation not optimal too. I think the correct interpretation is simply that a useflag is an ON/OFF switch for features.

If the existence of a program enables a feature of another installed program then it's an optional dependency and not controllable via useflags.
Comment 9 Pacho Ramos gentoo-dev 2012-06-10 19:15:32 UTC
I personally think it's worse to tell people to manually emerge gtk+:3 because, if later light-themes is removed, that gtk+-3 will be kept in system. Also, in the case of this package, I see no problem on having a gtk3 USE flag (for example, using gnome profile that tries to enforce gtk3 support, it will be pulled in while other people still not using any gtk3 app won't have it)
Comment 10 Julian Ospald 2012-06-10 19:20:21 UTC
(In reply to comment #9)
> I personally think it's worse to tell people to manually emerge gtk+:3
> because, if later light-themes is removed, that gtk+-3 will be kept in
> system.

Uhm, ebuilds are not for handholding. :P
Comment 11 Pacho Ramos gentoo-dev 2012-06-10 19:22:59 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > I personally think it's worse to tell people to manually emerge gtk+:3
> > because, if later light-themes is removed, that gtk+-3 will be kept in
> > system.
> 
> Uhm, ebuilds are not for handholding. :P

ebuilds need to pull their reverse dependencies to work, otherwise, dependencies are incomplete. And that dependency needs to be pulled in only when ebuild requires it or people manually want to have it, not because some dependencies are incomplete and later the dependency is there because people forget to manually unmerge it
Comment 12 Sebastian Pipping gentoo-dev 2012-06-10 19:27:53 UTC
(In reply to comment #8)
> > Would you stop calling my prior work "bogus", please?
> 
> Sry, didn't know that word is offensive. I'm just trying to clean up the
> gtk2/3 situation a bit.

It's German translation "Unsinn" is somewhat offensive to me and you seem to be German, too :-)

I'm actually glad you are helping clean up Gentoo, I'm just worried this very spot may a bad case.

> 
> > 
> > We agree that the flag actually does something
> 
> It _eventually_ does something. It should always do something.

Seriously, we could actually make that happen.  We could have the gtk3 use flag enable/disable the installation of files to

  /usr/share/themes/.../gtk-3.0

for this package.  That would reduce bloat at least.


> > I am unsure why to make a distinction between "fail to be usable" for a C
> > program and "fail to be usable" for another kind of language or data.  I do
> > not want to continue, before we have an answer to that.
> 
> Yes, I consider that explanation not optimal too. I think the correct
> interpretation is simply that a useflag is an ON/OFF switch for features.
> 
> If the existence of a program enables a feature of another installed program
> then it's an optional dependency and not controllable via useflags.

When it comes to important features, I tend to disaggree.
Fir instance the fact that no use-flag combination of dev-vcs/git results in a working "git instaweb" is a serious bug in my eyes -- the very same question.

Imagine someone has light-themes and gtk 3 installed.  Without the unity engine the theme is broken.  How is the user ever know that unico is missing if it's no dependency?  No, the emerge logs are not read by anyone.  On the other hand if unity was an unconditional dependency, it would pull in gtk 3 for users of gnome 2 or xfce.  So isn't a use flag a rather good solution to this problem?  It gets a lot worse once we remove it.

So seriously, how about making -gtk3 not install gtk-3.0 files and keep the use flag?
Comment 13 Julian Ospald 2012-06-10 19:33:07 UTC
(In reply to comment #12)
> (In reply to comment #8)
> > 
> > > 
> > > We agree that the flag actually does something
> > 
> > It _eventually_ does something. It should always do something.
> 
> Seriously, we could actually make that happen.  We could have the gtk3 use
> flag enable/disable the installation of files to
> 
>   /usr/share/themes/.../gtk-3.0
> 
> for this package.  That would reduce bloat at least.

That would suffice the useflag definition, yes. Please do it.
Comment 14 Sebastian Pipping gentoo-dev 2012-06-10 19:47:40 UTC
(In reply to comment #13)
> That would suffice the useflag definition, yes. Please do it.

+*light-themes-0.1.9.1-r1 (10 Jun 2012)
+
+  10 Jun 2012; Sebastian Pipping <sping@gentoo.org>
+  +light-themes-0.1.9.1-r1.ebuild:
+  No longer install gtk-3.0 files for USE=-gtk3 (bug #420569)
+
Comment 15 Sebastian Pipping gentoo-dev 2012-06-10 20:01:53 UTC
PS: If you would prefer to split light-themes up into 

  (2)  light-themes-0.1.9.1-r201
  (3)  light-themes-0.1.9.1-r301

no objections to re-open and do that from my side.
In that case the gtk-2.0 files should be deleted on the other end.

Pacho, would you object?
Comment 16 Julian Ospald 2012-06-10 20:06:11 UTC
Please only close this bug if gtk3 useflag has been dropped, cause that is what the tracker is about.

This does not need to be today, as it may be a migration issue, but it's for keeping track of it.

thanks
Comment 17 Pacho Ramos gentoo-dev 2012-06-10 20:16:27 UTC
(In reply to comment #15)
> PS: If you would prefer to split light-themes up into 
> 
>   (2)  light-themes-0.1.9.1-r201
>   (3)  light-themes-0.1.9.1-r301
> 
> no objections to re-open and do that from my side.
> In that case the gtk-2.0 files should be deleted on the other end.
> 
> Pacho, would you object?

I think it's not needed to complicate things so much, for example, :

- people like me wanting this theme  because it has support for both toolkits will now need to manually merge both SLOTs
- When will metacity stuff be put?
- Well, I know -r3xx usually mean gnome3 or gtk3... but I am unsure about users really understanding that behavior. If some package would depend on this package, it would make sense but... this is only a theme, a theme that is also usually installed because it tries to make gtk2/gtk3 apps look similar and, with that change, people would need to install both slots and also makes it more hard to maintain without no real benefit (I mean *real* benefit, seeing gtk3 USE flag cleaned is not a benefit per se)
Comment 18 Julian Ospald 2012-06-10 20:19:38 UTC
I don't have a strong opinion on this too, so just leave it open for now. It may not block stabilization.
Comment 19 Sebastian Pipping gentoo-dev 2012-06-10 20:40:33 UTC
(In reply to comment #16)
> Please only close this bug if gtk3 useflag has been dropped, cause that is
> what the tracker is about.
> 
> This does not need to be today, as it may be a migration issue, but it's for
> keeping track of it.
> 
> thanks

Alright, no problem.


(In reply to comment #17)
> I think it's not needed to complicate things so much, for example, :
> 
> - people like me wanting this theme  because it has support for both
> toolkits will now need to manually merge both SLOTs
> - When will metacity stuff be put?
> - Well, I know -r3xx usually mean gnome3 or gtk3... but I am unsure about
> users really understanding that behavior. If some package would depend on
> this package, it would make sense but... this is only a theme, a theme that
> is also usually installed because it tries to make gtk2/gtk3 apps look
> similar and, with that change, people would need to install both slots and
> also makes it more hard to maintain without no real benefit (I mean *real*
> benefit, seeing gtk3 USE flag cleaned is not a benefit per se)

Good point.

Interesting, how complicated such a small thing can get.