Hi Martin,

martin f krafft wrote:
also sprach Bart Samwel <[EMAIL PROTECTED]> [2007.06.16.2209 +0100]:
don't kill me, instead split acpi-support into acpi-support-ibm,
acpi-support-toshiba, … please? :)
Sorry, I think I have to refuse this one (without killing you ;-) ). There are various reasons for not wanting this:

Thanks for taking the time to argue your position. wontfix is
acceptable for me, but I still challenge it a bit below:

OK, let me try to respond to your concerns again!

* The acpi-support package is intended to contain a library that
associates laptop models and the required package behaviours. Many
of the behaviours are not as clear-cut as "toshiba" vs. "ibm"
versus "dell" versus "asus".

so how about acpi-support-common?

Like I said, the parts aren't so cleanly separable. Most of the stuff *is* common. :-)

* apt cannot detect the specific laptop model, this detection is
left to acpi-support. Therefore, acpi-support *must* be able to
support all laptops out-of-the-box, *or* it must detect the
laptops and install the additional packages automatically. But
this would again require knowledge about the existing laptop
models in the core package, which would defeat the entire purpose
of splitting the package up!

you can provide acpi-support which depends on acpi-support-*. Please
see how xorg-video-drivers-all works.

I see, but that means that you always have to install everything anyway. Unless you split into -common, -<laptop brand> and -all. But that would be a REALLY complicated solution, while the laptop-specific stuff is REALLY small. Definitely overkill.

* The split would yield a lot of *very* small packages, consisting
only of a couple of settings and a tiny number of config files.
This is probably overkill.

Well, it would allow me to use acpi-support and actually make sense
of /etc/acpid/* by removing all the stuff that I will never need.
This is Debian, after all...

I'd rather improve the organization of the package (which it definitely needs) than splitting it up. You see, it's not a large package, it's just a bit disorganized. And that's the fault of upstream (which is Ubuntu). Anyway, I want to avoid at all cost that the user needs to manually select the right package for his/her laptop to work. The only problem here is really that these files are in the config directory, while they really contain package code. I'd much rather fix that instead.

Cheers,
Bart

Reply via email to