Bug 508096 - split gnome-power-manager to avoid dependency on gnome-panel-libs
split gnome-power-manager to avoid dependency on gnome-panel-libs
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-25 11:48 EDT by Bernie Innocenti
Modified: 2010-12-05 01:47 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:47:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch for spec file (4.55 KB, patch)
2009-08-29 18:08 EDT, Bernie Innocenti
no flags Details | Diff

  None (edit)
Description Bernie Innocenti 2009-06-25 11:48:36 EDT
gnome-power-manager brings in gnome-panel-libs due to
gnome-brightness-applet and gnome-inhibit-applet.

if we could split these to a separate package, we could get rid of this unneeded dependency for Sugar on a Stick.
Comment 1 Richard Hughes 2009-06-25 11:58:37 EDT
Sure, feel free to split gnome-power-manager into gnome-power-manager+gnome-power-manager-applets if this makes things easier. I do worry that gnome-power-manager-applets won't be dragged in for new installs.

So yes, if we do this carefully it's possible.
Comment 2 Bernie Innocenti 2009-06-25 12:09:45 EDT
I think the canonical workaround is splitting into two
packages with new names:

   gnome-power-manager-daemon
   gnome-power-manage-applet

and then make both "Obsolete: gnome-power-manager".  Would that work?

I think we'd also have to update the comps to get these two packages included by default in new installations.
Comment 3 Richard Hughes 2009-06-25 12:27:01 EDT
(In reply to comment #2)
>    gnome-power-manager-daemon

No, that's horrible. Everyone knows the package as gnome-power-manager.
Comment 4 Bernie Innocenti 2009-06-25 12:45:14 EDT
Here it says we could achieve what we need without renaming the main package by doing a double-obsolete:

  http://yum.baseurl.org/wiki/YumPackageUpdates#Packagesplit

OK to take this route?
Comment 5 Richard Hughes 2009-06-26 08:03:02 EDT
Sure, sounds like a plan to me. +1 from me, but any breakage will be pointed at you :-)
Comment 6 Matthias Clasen 2009-08-29 14:10:23 EDT
Can we get this done soon ?
Comment 7 Bernie Innocenti 2009-08-29 18:07:06 EDT
Sorry, I forgot about this bug.  Here's my proposed split:

  http://koji.fedoraproject.org/koji/taskinfo?taskID=1643377

I'm also attaching the .spec diff.  If it looks right, I'll commit to CVS and call a rebuild in rawhide.
Comment 8 Bernie Innocenti 2009-08-29 18:08:28 EDT
Created attachment 359174 [details]
patch for spec file
Comment 9 Richard Hughes 2009-08-30 04:15:26 EDT
Please don't commit yet:

-Requires: gtk2 >= 2.10.0
-Requires: gnome-icon-theme

Why not?

-Requires: unique >= 0.9.4

gnome-power-preferences and gnome-power-statistics need this as a runtime dep.

 Requires: DeviceKit-power >= 008
-Requires(post): scrollkeeper

? The mail package needs to ship the documentation...

-%{_bindir}/gnome-power-preferences
-%{_datadir}/gnome-power-manager/gpm-prefs.ui
-%{_datadir}/gnome-power-manager/gpm-feedback-widget.ui
-%{_mandir}/man1/gnome-power-preferences.1.gz
+
+%files applets -f %{name}.lang
+%{_bindir}/gnome-power-preferences

Why? You've moved the preferences to the applet subpackage...

+%{_mandir}/man1/gnome-power-preferences.1.gz
 %{_datadir}/omf/gnome-power-manager
+%{_datadir}/applications/gnome-power-preferences.desktop
+%{_datadir}/gnome-power-manager/gpm-prefs.ui
+%{_datadir}/gnome-power-manager/gpm-feedback-widget.ui

And the feedback widget! The daemon needs this!

I think the patch needs a lot more work.

Richard.
Comment 10 Matthias Clasen 2009-08-30 20:07:42 EDT
Let me answer some of these:

> -Requires: gtk2 >= 2.10.0
> -Requires: gnome-icon-theme
> 
> Why not?

Presumably because we should already have library deps against gtk, and there is no version of Fedora where the version could be relevant (also, pretty sure that gpm uses newer GTK+ features than 2.10...)

> -Requires: unique >= 0.9.4
> 
> gnome-power-preferences and gnome-power-statistics need this as a runtime dep.

Library dep is enough ?

> -Requires(post): scrollkeeper
> 
> ? The mail package needs to ship the documentation...

Look at the output of scrollkeeper-update --help. It says:

NOTE (2): This script doesn't do anything and is 
only provided for scrollkeeper compatibility


Your comments on the file list changes seemed to be right on the mark though.
Comment 11 Bernie Innocenti 2009-09-01 15:07:48 EDT
(In reply to comment #9)
> Please don't commit yet:
> 
> -Requires: gtk2 >= 2.10.0
> -Requires: gnome-icon-theme
> 
> Why not?

The diff is unclear.  These just moved to the applets package.
Afaik, the power manager daemon does not depend on gtk.

 
> -Requires: unique >= 0.9.4
> 
> gnome-power-preferences and gnome-power-statistics need this as a runtime dep.

I moved those to the applets package as well.


>  Requires: DeviceKit-power >= 008
> -Requires(post): scrollkeeper
> 
> ? The mail package needs to ship the documentation...

scrollkeeper-update is now a now a no-op, afaiu.  So we can get rid of it.


> -%{_bindir}/gnome-power-preferences
> -%{_datadir}/gnome-power-manager/gpm-prefs.ui
> -%{_datadir}/gnome-power-manager/gpm-feedback-widget.ui
> -%{_mandir}/man1/gnome-power-preferences.1.gz
> +
> +%files applets -f %{name}.lang
> +%{_bindir}/gnome-power-preferences
> 
> Why? You've moved the preferences to the applet subpackage...

The motivation for splitting the package is to make the base gnome-power-manager package independent of the gnome desktop components.  Perhaps
"gnome-power-manager-applets" is not a good name for it, but "gnome-power-manager-gnome" would have sounded redundant.

Maybe "gnome-power-manager-gui" would work better?


> +%{_mandir}/man1/gnome-power-preferences.1.gz
>  %{_datadir}/omf/gnome-power-manager
> +%{_datadir}/applications/gnome-power-preferences.desktop
> +%{_datadir}/gnome-power-manager/gpm-prefs.ui
> +%{_datadir}/gnome-power-manager/gpm-feedback-widget.ui
> 
> And the feedback widget! The daemon needs this!

Is this really being invoked directly by the daemon?
Because it would seem like a layering violation if it wasn't done
through dbus or something like this.


> I think the patch needs a lot more work.

Sure, I'm willing to do what's needed at this point :-)
Comment 12 Richard Hughes 2009-09-01 19:37:37 EDT
(In reply to comment #11)
> I moved those to the applets package as well.

The apps are not applets...

> scrollkeeper-update is now a now a no-op, afaiu.  So we can get rid of it.

Sure, okay.

> The motivation for splitting the package is to make the base
> gnome-power-manager package independent of the gnome desktop components. 

That's not what comment 1 suggests.

> Maybe "gnome-power-manager-gui" would work better?

No, that would be ridiculous,

> > And the feedback widget! The daemon needs this!
> 
> Is this really being invoked directly by the daemon?
> Because it would seem like a layering violation if it wasn't done
> through dbus or something like this.

Yes it is, but I see no layering problem. What exact problem are you expecing to solve by splitting the package?

Splitting out the applets is one thing, what you're proposing is quite another.
Comment 13 Matthias Clasen 2009-09-01 20:56:44 EDT
Bernie, there may be some misunderstanding caused by historical naming, here.

What is called a "daemon" is essentially the in-session gui component of power mgmt. The actual 'daemon' role is played by DeviceKit-power nowadays.

So, I agree with Richard that all that a split can achieve is to drop the (somewhat crazy) applets, and thus get rid of the libpanel-applet dependency.
Even after that, gnome-power-manager still is a gui tool that will have a GTK+ dependency. The gnome-icon-theme dependency looks suspicious to me, though. It should probably be dropped, anyway.
Comment 14 Bernie Innocenti 2009-09-02 00:49:13 EDT
Ok, understood.  I had even forgotten what my original motivation was,
my patch ended up being too aggressive.

I'll resubmit something acceptable soon, thanks for taking the time to
review this work, and please be patient with me as my Gnome backgriund
is somewhat limited.
Comment 15 Bug Zapper 2009-11-16 05:26:44 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2010-11-04 06:58:23 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bug Zapper 2010-12-05 01:47:44 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.