On Sat, Jan 19, 2019 at 10:34:02AM +0000, Mark Hindley wrote: [cut]
> > > > That seems unfortunate as the two packages are not exact functional > > replacements of each other, but it would solve this particular problem. > > Yes I agree, but I cannot see a way for elogind to tell if another handler is > also listening to lid events. > I guess it might make sense to let the user decide. acpi and elogind serve different needs, even if some of the use-cases overlap. I think it is in general best to avoid to make decisions on behalf of the users, unless strictly necessary. There is little or zero probability that a "desktop-user" will get acpi-support installed, unless they want to. On the contrary, there are several applications which require elogind for things unrelated to the management of acpi events (think of anything that requires libpam-systemd, for instance...). My impression is that making elogind Conflict: with acpi-support is irrelevant for most elogind users, and a potential source of breakage for acpi-support users. A typical loss-loss case, IMHO. Users should be warned of potential interactions among the two packages, but not deprived of the freedom to handle and resolve those interactions if they like to, IMHO. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ]
signature.asc
Description: PGP signature