Joey Hess wrote:
Bart Samwel wrote:
OK, then we'll do that. I'll have to think about how I'm going to do this
split without diverging from the upstream too much. I haven't been keeping
an eye on the Debian release schedule, could you give me an estimated time
line when this needs to have been fixed?
Well, acpid is currently scheduled to reash testing in er, 25 days
(thanks to the RMs for looking at the situation and adding some grace time).
Once that happens, newly installed systems won't handle powerbtn events
anymore, which I think is going to add to the d-i support load.
OK, I guess we have a time line then.
Of course, upgraded systems already fail to do this, and unless someone
thinks of a transition plan to get acpi-support-base installed on
systems with acpid (other than laptops, which already have acpi-support
on them), fixing it will be up to the admin (and would need to be
documented in the lenny release notes, too).
Let me think if I can come up with something... The easiest upgrade plan
would be to let acpid depend on acpi-support-base. People can always
remove the config files of acpi-support base if they don't like them,
just like they could always remove the powerbtn handler that acpid used
to install. Or, if you want to do it fancy and if you want to allow
people to uninstall acpi-support-base, you could rename acpid to
something like "acpi-daemon", and make acpid a transitional metapackage
that depends on acpi-support-base and acpi-daemon. Doesn't make it
_logical_ (I mean, acpid should be in the acpid package), but I guess it
will work...
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
