---------- Forwarded Message ----------
Subject: Re: Proposal for resolving powernowd/apmd vs. (k)powersave conflict
Date: Thursday 09 March 2006 11:56
From: Achim Bohnet <[EMAIL PROTECTED]>
To: Kubuntu Developer Discussion <[EMAIL PROTECTED]>
On Thursday 09 March 2006 00:33, Luka Renko wrote:
> Hello,
>
> I am still looking how to make usable powersaved/kpowersave packages that
> would not clash with kubuntu-desktop (and hopefully also ubuntu-desktop and
As klaptop is dead upstream, it's have to work on *powersave* integration.
Or is there any alternative?
> edubuntu-desktop). As you may know, the main problem is that powernowd and
> apmd packages are not compatible with powersaved (as they do the same stuff
> and there are known issues if both run at the same time). Debian powersaved
> package has a rule to remove apmd and powernowd, which then also removes
> *-desktop packages. :-(
>
> I would suggest the following workaround for this "catch22" problem:
>
> 1. Get rid of "Conflicts: powernowd apmd" rule
> This will allow powersaved/kpowersave to be installed on Kubuntu (including
> the case where ubuntu/edubuntu-desktop is there). As this can lead to known
> issues, we will also...
>
> 2. Change "/etc/init.d/powersaved start" to stop powernowd/apmd before
> starting powersaved
> Start should just call "stop" methods of powernowd/apmd rc scripts. Good
> thing is that powersaved is started after powernowd and ampd:
> /etc/rc3.d/S20apmd
> /etc/rc3.d/S20powernowd
> /etc/rc3.d/S25powersaved
As a security measure, until we find a better way, I would suggest that
we (dpkg-0divert apmd and powernowd. So they can't be started by addicent.
> That way user could decide to keep existing powernowd/klaptop solution or
> switch to powersaved/kpowersave which will override already installed
> powernowd/ampd.
> I am not sure if such solution would have additional side effects for
> gnome-power-manager in case that user would have both GNOME and KDE
> installed and would change DE for different login sessions. I think g-p-m
> has to cope with such case, as apmd is anyway not running on ACPI machines
> and some CPUs also do not support CPU frequency changes (if there is no
> cpufreq module loaded, powernowd is probably not started - need to check).
We need testing feedback. I suggest to make these changes you described,
upload to a private repo and accounce it with pros _and_ cons. It should
be clear that this is a test tree to get better integration.
> Questions:
> 1. Do we need to care about cpudyn/cpufreqd (also conflicting packages)
> that are in universe but not installed by *-desktop?
> If yes, I could check them and see if similar workaround is possible
> also there.
> 2. Is such solution too ugly to be accepted into universe (will not pass
> revu process)?
do same as with powernowd, stop it (and divert away). No conflicts because
the deinstalled pkgs are not automaticly installed on deinstallation.
This is a bit dirty, but during integration/testing/feedback phase,
but restore state after deinstallation.
> 3. Is it at all possible to push UpstreamVersionFreeze exception for such
> packages? And that late in release cycle?
We will have the identical integration problem for dapper+1. So let's not
care about UVF for now. One should just try choose simple changes.
We there's enough good feedback/testing, arguing for an UVF is much easier.
But first prio is to get testing feedback!
> 4. How much do we need to investigate impact on GNOME (g-p-m) for cases
> where powernowd/apmd are not running?
first any pending issues with KDE, then look at GNOME. This way we can
at least provide a out of Kubuntu repo solution for _KDE-only_ users.
> I would really like to see your comments about this proposal. Therefore any
> feedback will be more than welcome.
>
> Note: I plan to use kpowersave with my Dapper install no matter what -
> therefore if we will not be able to push latest kpowersave into universe, I
> plan to create my own packages (I am still learning package creation ;-))
> and share it for whoever might see them useful.
Great!
a) make it rock for KDE in with an outside repo as quick as possible
b) check what can be done in term of gnome coexistance
when a) and b) are done
c) think about UVF
whatever happens we will have then a (private repo) solution for dapper and
a good base for dapper+1 if UVF fails.
Achim
> Regards,
> Luka
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- [EMAIL PROTECTED]
--
kubuntu-devel mailing list
[EMAIL PROTECTED]
https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
-------------------------------------------------------
_______________________________________________
powersave-devel mailing list
[email protected]
http://forge.novell.com/mailman/listinfo/powersave-devel
