KatolaZ | amesser: you here? | 12:27 |
---|---|---|
amesser | KatolaZ: he're i'am | 13:53 |
LeePen | Just been reading the debian-devel libpam-systemd/elogind thread. | 15:18 |
LeePen | If we remove Provides libpam-systemd from elogind to make acceptable to Debian could we have a Devuan specific package which Depends libpam-elogind and Provides libpam-systemd to glue it all together? | 15:22 |
amesser | good question | 15:23 |
amesser | point is, from debian view point either libpam-elogind or libpam-systemd should be installed. Never both | 15:23 |
amesser | imho would be better to have a more general virtual package, e.g "session-management-login" which is provided by libpam-systemd nd libpam-elogind | 15:25 |
amesser | application should depend on that then, and not on libpam-systemd | 15:25 |
LeePen | Yes, that is cleaner, but as is pointed out in the thread libpam-system provides more than libpam-elogind. They are not equivalent. | 15:27 |
amesser | that is true | 15:27 |
amesser | but no one is using libpam-systemd directly | 15:27 |
amesser | libsystemd maybe, but libpam-systemd is nothing else that the pam module which is executed on login | 15:28 |
KatolaZ | but we can't rebuild all the packages that Depends: libpam-systemd | 15:28 |
KatolaZ | ... | 15:28 |
amesser | no application should depend on that module anyway | 15:28 |
KatolaZ | that's why we decided to make elogind Provides: libpam-systemd | 15:28 |
amesser | since you can not use it outside of pam :-) | 15:28 |
amesser | KatolaZ: what we could do is make a glue oacket, maybe | 15:28 |
amesser | packet | 15:29 |
KatolaZ | how? | 15:29 |
KatolaZ | it'a a packet that provides | 15:29 |
amesser | just an empty packet: libpam-elogind-glue | 15:30 |
amesser | Provides libpam-systemd | 15:30 |
KatolaZ | and Depends: elogind | 15:30 |
amesser | Requires libpam-elogind | 15:30 |
amesser | ah, yes | 15:30 |
KatolaZ | well it's a possibility | 15:30 |
LeePen | Yes, that it what I meant | 15:30 |
KatolaZ | wouldn't change much for Devuan | 15:30 |
KatolaZ | but wouldn't solve the problem in Debian either | 15:30 |
KatolaZ | since you have to pin down libpam-systemd | 15:30 |
KatolaZ | (it's the name of an actual package, remember) | 15:31 |
KatolaZ | we don't have this problem in Debian since libpamsystemd is banned | 15:31 |
KatolaZ | but in Debian you would have a concrete package with the same name of a virtual feature | 15:31 |
KatolaZ | and I guess that is not allowed by Policy | 15:31 |
KatolaZ | (but I might be wrong on the latter point) | 15:32 |
LeePen | I looked last week and the Policy doesn't ban it | 15:32 |
LeePen | but clearly it is not favoured in the thread of the last few days. | 15:32 |
KatolaZ | ok, but that package should Provides, Breaks, and Conflict with libpamsystemd | 15:32 |
amesser | I don't like having extra glue package in Devuan. Its curing the problem at the wrong place. But I could live with it. | 15:33 |
LeePen | Yes. I suppose it all comes down to what we want to achieve. | 15:33 |
LeePen | If we are happy to maintain a slightly different lp-elogind in Devuan | 15:34 |
KatolaZ | the problem I see atm is how any package that Depends: libpam-systemd can use elogind (in Debian) | 15:34 |
KatolaZ | again, it's not a problem in Devuan | 15:35 |
KatolaZ | since there is no such package except elogind | 15:35 |
KatolaZ | but this is not gonna work in Debian | 15:35 |
KatolaZ | unless you ask rdeps to adjust their deps on something that should be yet be agreed upon... | 15:35 |
KatolaZ | :\ | 15:35 |
amesser | When they want go without systemd in Debian, they also need the glue package :-) | 15:35 |
LeePen | The debian-devel thread recommends a MBF | 15:36 |
amesser | But maybe we can have at least elogind package itself the same one for Debian and Devuan | 15:36 |
amesser | MBF? | 15:36 |
LeePen | Mass bug filling | 15:36 |
KatolaZ | mass bug-filing | 15:37 |
amesser | hmm | 15:37 |
amesser | gonna read more about this concept :-) | 15:37 |
amesser | anyway, if it helps the debian people, we can simply make such a glue package. Maybe such a glue can be more global, not only libpam-elogind but also depend on polkit-elogind.... This will help to prevent the consolekit/elogind polkit mismatch issues we had with ascii in the first place | 15:40 |
amesser | will be off for a while.. | 15:42 |
amesser | see ya later this evening | 15:42 |
LeePen | Yes. KatolaZ: you said such a glue package wouldn't change much for Devuan, but it would mean we didn't have to recompile all the Debian packages which depend on libpam-systemd | 15:43 |
LeePen | Or have I misunderstood you? | 15:43 |
amesser | we dont have to at the moment either | 15:44 |
amesser | since we have Provides: libpam-systemd at the moment | 15:44 |
amesser | as i said, no one directly accesses libpam-systemd | 15:44 |
amesser | this depenedency just makes sure, that systemd-logind/elogind session management is installed in the system | 15:45 |
LeePen | Yes, this is only an issue if we remove the Provides libpam-systemd to get elogind into Debian | 15:45 |
amesser | ah ok, sry | 15:45 |
KatolaZ | LeePen: we don't need to recompile any package in devuan if we have something that Provides: libpam-systemd | 15:46 |
LeePen | Yes. And if we drop Provides libpam-systemd from | 15:47 |
KatolaZ | but apparently there is no agreement in Debian about the fact that elogind can effectively Provide: libpam-systemd | 15:47 |
KatolaZ | 'cause they have said that some packages need libpam-systemd AND `systemd --user` in order to work properly | 15:47 |
LeePen | elogind to get it into Debian we could use a Devuan specific | 15:47 |
LeePen | glue package to mean we didn't have to | 15:48 |
LeePen | recompile the Debian pacakges that still only depended on lp-systemd | 15:49 |
kilobyte | this is bikeshed naming, but a name picked by smcv (one of systemd maintainers) was: Depends: default-logind | logind | 15:49 |
kilobyte | wrt systemd --user: as far as I know, all such packages already depend on systemd directly | 15:50 |
KatolaZ | TBH, I wouldn't change elogind in Devuan unless we know that the change will be meaningful (i.e., that we can use the same package as Debian) | 15:56 |
KatolaZ | I mean, if we change something and then in the end we still need to maintain out own version of elogind, there is not much point into it | 15:57 |
KatolaZ | s/out/our | 15:57 |
LeePen | Yes, absolutely. | 15:58 |
LeePen | So I am suggesting this as part of getting elogind into Debian so | 15:59 |
KatolaZ | yes, I get it | 15:59 |
LeePen | that non-systemd inits are more viable there. | 15:59 |
KatolaZ | but there is apparently some resistance to that | 16:00 |
LeePen | There may be, but I couldn't see that in the d-devel thread. Suggestions for what needs to be done.. | 16:01 |
LeePen | Have you heard/seen positive resistance? | 16:02 |
KatolaZ | dunno | 16:18 |
KatolaZ | the requirement to change the dep to default-logind | logind looks like a MBF | 16:18 |
LeePen | Yes, but even that could only happen after elogind was in Debian. It is a bit chicken and egg. | 16:23 |
LeePen | Maybe I am getting ahead of myself. I will finish 239.1 for Devuan and see where we are then. | 16:49 |
LeePen | Thanks | 16:49 |
KatolaZ | thank you LeePen | 16:49 |
KatolaZ | thanks a lot for you work on that | 16:49 |
KatolaZ | :) | 16:49 |
KatolaZ | I really appreciate that | 16:49 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!