> "Michael" == Michael Biebl writes:
Michael> On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
Michael> wrote:
>> The bulk of the bug is a discussion about the general approach to
>> allowing Debian users to choose between systemd and elogind (and,
>> therefore, allowing
On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
wrote:
> The bulk of the bug is a discussion about the general approach to
> allowing Debian users to choose between systemd and elogind (and,
> therefore, allowing them to run desktoppy kind of software without
> systemd). As discussed it seems
Processing control commands:
> close -1
Bug #940034 [libelogind0] libelogind0: replacing a core system library and
conflicting against the default init considered harmful
Marked Bug as done
--
940034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940034
Debian Bug Tracking System
Contact
Control: close -1
Hi. I have been asked to take a look at this bug. I've reviewed the
bug log and tried to identify what the issues are that this bug is
about.
The title is an objection to the Conflicts/Replaces/Provides.
I confess I found the bug log rather diffuse. Many different people
On Sun, 6 Oct 2019, Andreas Messer wrote:
> As of my thinking, the only proper solution here would be to kindly, well
> forcefully insist on systemd upstream to split their library by function
Good chance of *that* but thanks I needed a laugh…
bye,
//mirabilos
--
«MyISAM tables -will- get
I have been reading on this bug for a while now.
On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> Would it be any help at all of the "dbus client-ish" bits and the
> "direct API-ish" bits of the two libraries were split up into two
> separate libraries? i.e. would that allow the
On Sun, 29 Sep 2019, Mark Hindley wrote:
> On Sat, Sep 28, 2019 at 11:41:56AM +0200, Thorsten Glaser wrote:
> > On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote:
> >
> > > 1. install sysvinit-core; that removes systemd-sysv but nothing else
> > >systemd related
> >
> > > Souldn't that
Cristian,
On Sat, Sep 28, 2019 at 11:41:56AM +0200, Thorsten Glaser wrote:
> On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote:
>
> > 1. install sysvinit-core; that removes systemd-sysv but nothing else
> >systemd related
>
> > Souldn't that work?
>
> It would, if but for libpam-systemd
On Sat, 28 Sep 2019, Thorsten Glaser wrote:
> On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote:
>
> > 1. install sysvinit-core; that removes systemd-sysv but nothing else
> >systemd related
>
> > Souldn't that work?
>
> It would, if but for libpam-systemd having a (somewhat questionable
On Sat, Sep 28, 2019 at 02:53:56AM +0200, Thorsten Glaser wrote:
> On Fri, 27 Sep 2019, Mark Hindley wrote:
>
> > Thanks. The aim of preventing accidental removal of systemd is very
> > reasonable. However, using this approach the hurdle you create even to a
> > user
> > who really wants to
On Fri, 27 Sep 2019, Julien Cristau wrote:
> So one thing I think we should ensure is we don't end up uninstalling
> systemd without an explicit user choice.
I’ve proposed to suggest to the systemd maintainers to add
Important: yes to libsystemd0. (On a different level, adding
it to systemd
On Fri, 27 Sep 2019, Mark Hindley wrote:
> Thanks. The aim of preventing accidental removal of systemd is very
> reasonable. However, using this approach the hurdle you create even to a user
> who really wants to uninstall is pretty high. Few people will continue having
> seen the 'You are about
On Fri, 27 Sep 2019, Adam Borowski wrote:
> > The "init" package has the "Important: yes" control field which as I
> That flag is not for "without an explicit user choice". It's for "you're
> breaking the packaging system, far more than ignoring dependencies".
This is wrong.
> It's the
On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote:
> 1. install sysvinit-core; that removes systemd-sysv but nothing else
>systemd related
> Souldn't that work?
It would, if but for libpam-systemd having a (somewhat questionable
but understandable) dependency on systemd-sysv. This is
On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote:
> On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote:
> So one thing I think we should ensure is we don't end up uninstalling
> systemd without an explicit user choice.
Julien,
I appreciate that you are suggesting some
Mark,
On Fri, 27 Sep 2019, Mark Hindley wrote:
>
> Thanks. The aim of preventing accidental removal of systemd is very
> reasonable. However, using this approach the hurdle you create even
> to a user who really wants to uninstall is pretty high. Few people
> will continue having seen the
Julien,
On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote:
> So one thing I think we should ensure is we don't end up uninstalling
> systemd without an explicit user choice.
>
> The "init" package has the "Important: yes" control field which as I
> understand it tells apt to behave
On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote:
> So one thing I think we should ensure is we don't end up uninstalling
> systemd without an explicit user choice.
>
> The "init" package has the "Important: yes" control field which as I
> understand it tells apt to behave like
On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote:
> I think it is fair to ask Julien as the bug submitter to engage here
> either by coming up with new options that none of us have explored or by
> coming up with specific problems. Alternatively it would be reasonable
> for him to ask
Sam,
On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote:
> > "Mark" == Mark Hindley writes:
>
> Mark> Sam, Since I cannot get a working and robust dpkg-divert
> Mark> solution, I feel the need to revisit the validity of these
> Mark> concerns.
>
> I'd like to push back
Hello Sam,
> What i'm hearing is that after spending a couple of weeks exploring ways
> to meet these concerns, you'd now like to push back on whether they are
> a good idea in the first place.
> That seems dismissive both of Julien's concerns and the engineering
this is a completely wrong
> "Mark" == Mark Hindley writes:
Mark> Sam, Since I cannot get a working and robust dpkg-divert
Mark> solution, I feel the need to revisit the validity of these
Mark> concerns.
I'd like to push back on the phrasing here.
What i'm hearing is that after spending a couple of weeks
On Thu, Sep 26, 2019 at 12:52:27PM +0200, Thorsten Glaser wrote:
> On Thu, 26 Sep 2019, Mark Hindley wrote:
> > It is possible to get APT to attempt a solution by specifically requesting
> > 'apt
> > install libelogind0 sysvinit-core'. This removes systemd-sysv and then
> > fails
>
> Does it
On Thu, Sep 26, 2019 at 12:52:27PM +0200, Thorsten Glaser wrote:
> On Thu, 26 Sep 2019, Mark Hindley wrote:
>
> > It is possible to get APT to attempt a solution by specifically requesting
> > 'apt
> > install libelogind0 sysvinit-core'. This removes systemd-sysv and then
> > fails
>
> Does
On Thu, 26 Sep 2019, Mark Hindley wrote:
> It is possible to get APT to attempt a solution by specifically requesting
> 'apt
> install libelogind0 sysvinit-core'. This removes systemd-sysv and then fails
Does it also request a “Yes, do as I say!” then?
If not (or perhaps anyway) libsystemd0
Sam,
Since I cannot get a working and robust dpkg-divert solution, I feel the need to
revisit the validity of these concerns.
On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
> > "Mark" == Mark Hindley writes:
> >> If we are going to use c/r/p libsystemd0, is there some way
On Thu, Sep 26, 2019 at 12:11:47AM +0200, Thorsten Glaser wrote:
> On Wed, 25 Sep 2019, Mark Hindley wrote:
>
> > Thanks. Triggers may be an answer to the libsystemd soversion issue.
>
> Mind that anything that runs between unpacking the new libsystemd0
> and running the trigger will use
On Wed, 25 Sep 2019, Mark Hindley wrote:
> Thanks. Triggers may be an answer to the libsystemd soversion issue.
Mind that anything that runs between unpacking the new libsystemd0
and running the trigger will use libsystemd0 instead of libelogind0.
> > I don’t like this approach.
>
> In this
On Wed, Sep 25, 2019 at 10:09:15PM +0200, Thorsten Glaser wrote:
> On Wed, 25 Sep 2019, Mark Hindley wrote:
>
> > libelogind0 can be coninstalled with libsystemd0. However, it is fragile
> > because
> > the file that needs to be diverted out of the way is libsystemd.so.0.26.0
> > (the
> >
On Wed, 25 Sep 2019, Sam Hartman wrote:
> Thorsten> dpkg-divert also has a small period in which neither is
> Thorsten> available. I don’t like this approach.
>
> Is that only when adding a diversion or when upgrading a diverted file
> each time?
When adding a diversion. dpkg-divert is
> "Thorsten" == Thorsten Glaser writes:
Thorsten> On Wed, 25 Sep 2019, Mark Hindley wrote:
>> libelogind0 can be coninstalled with libsystemd0. However, it is
>> fragile because the file that needs to be diverted out of the way
>> is libsystemd.so.0.26.0 (the actual library
On Wed, 25 Sep 2019, Mark Hindley wrote:
> libelogind0 can be coninstalled with libsystemd0. However, it is fragile
> because
> the file that needs to be diverted out of the way is libsystemd.so.0.26.0 (the
> actual library file, not a symlink) otherwise ldconfig will still find it and
> create
On Mon, Sep 23, 2019 at 04:16:05PM -0400, Sam Hartman wrote:
> Mark> Anyway, I am happy to try to work up a dpkg-divert solution if
> Mark> that is likely to be more acceptable.
>
> I don't know if it will be.
> I'm trying to be a facilitator here and make sure all sides understand
> each
On Mon, 23 Sep 2019, Sam Hartman wrote:
> Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that
> Mark> installed I can no longer reproduce #934491. The APT
> Mark> maintainers have said that adding a Breaks for the fixed
> Mark> version of apt is not useful.
>
>
On Tue, 2019-09-24 at 10:05 +0100, Mark Hindley wrote:
> Ian,
>
> Thanks for this.
>
> On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> > On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> > Would it be any help at all of the "dbus client-ish" bits and the
> > "direct
Ian,
Thanks for this.
On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> Would it be any help at all of the "dbus client-ish" bits and the
> "direct API-ish" bits of the two libraries were split up into two
> separate
On Tue, 24 Sep 2019 07:28:29 +0800
Ian Campbell wrote:
> Has anyone investigated late dynamic binding using a stub library
> which merely determines which init is running and then dlopens the
> appropriate libsystemd0 of libelogind0 library and forwards the calls
> to it?
it could be in the
On Fri, 2019-09-20 at 10:16 +0100, Mark Hindley wrote:
> On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> > Hello,
> >
> > When I looked I elogind a while back I was able to build a package without
> > having a public libelogind0, I basically had that in my debian/rules file:
> "Mark" == Mark Hindley writes:
Mark> On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
>> Foo-package depends on the latest libsystemd0. I'm running
>> unstable or testing. The latest libsystemd0 isn't building on my
>> arch yet. But elogind is simpler and has
On Mon, Sep 23, 2019 at 03:34:50PM -0400, Sam Hartman wrote:
> Hi.
> I've looked a bit at the systemd code as compared to the elogind code.
>
> One of the major reasons that libsystemd0 cannot be used as a
> replacement for libelogind0 is that elogind does not have compatible
> cgroup naming.
>
On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
> Foo-package depends on the latest libsystemd0. I'm running unstable or
> testing. The latest libsystemd0 isn't building on my arch yet. But
> elogind is simpler and has build fine on my arch. I install foo-package
> and suddenly
Hi.
I've looked a bit at the systemd code as compared to the elogind code.
One of the major reasons that libsystemd0 cannot be used as a
replacement for libelogind0 is that elogind does not have compatible
cgroup naming.
The systemd (and elogind) libraries do some operations over dbus.
But other
> "Mark" == Mark Hindley writes:
>> If we are going to use c/r/p libsystemd0, is there some way we
>> can limit the potential damage to people who have positively
>> indicated that they want to run a non-default init system? One
>> of the concerns is what happens if apt
Sam,
Many thanks for this.
On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote:
Mark> I have tried the approach suggested by Laurent of using
Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs
Mark> to function correctly.
> What trouble did you run into?
That
On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote:
> Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that
> Mark> installed I can no longer reproduce #934491. The APT
> Mark> maintainers have said that adding a Breaks for the fixed
> Mark> version of apt is
> "Mark" == Mark Hindley writes:
Mark> Julian,
Mark> On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote:
>> > I don't think it's reasonable to ship this package with C/R/P >
>> libsystemd0.
>>
>> I understand that you don't like it. However, for libelogind0
Julian,
On Wed, Sep 11, 2019 at 02:28:55PM +0100, Mark Hindley wrote:
> > I don't think it's reasonable to ship this package with C/R/P
> > libsystemd0.
>
> I understand that you don't like it. However, for libelogind0 to export the
> same
> symbols as libsystemd0 so that it could C/R/P
Laurent,
On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> Hello,
>
> When I looked I elogind a while back I was able to build a package without
> having a public libelogind0, I basically had that in my debian/rules file:
>
> # We only build the libelogind0 and
Laurent,
On Fri, Sep 20, 2019 at 01:29:43PM +0200, Laurent Bigonville wrote:
> Can't this be stubbed or mocked on the elogind side?
I presume you mean slices here? (I am not sure that slices are the only
difference in implementation, but let's ignore that for now).
To be honest, I am not sure.
On 20/09/19 11:16, Mark Hindley wrote:
On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
[...]
Bottom line, is libelogind even needed in the archive to achieve your goal
of having an implementation of the login1 D-Bus API not requiring systemd as
PID1?
Thanks.
I think you
On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> Hello,
>
> When I looked I elogind a while back I was able to build a package without
> having a public libelogind0, I basically had that in my debian/rules file:
>
> # We only build the libelogind0 and libelogind-dev if we
On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote:
> When I looked I elogind a while back I was able to build a package without
> having a public libelogind0, I basically had that in my debian/rules file:
>
> # We only build the libelogind0 and libelogind-dev if we are building
Hello,
When I looked I elogind a while back I was able to build a package
without having a public libelogind0, I basically had that in my
debian/rules file:
# We only build the libelogind0 and libelogind-dev if we are building for
# Devuan or its derivatives
ifneq ($(shell dpkg-vendor
Julien,
Thank you.
On Wed, Sep 11, 2019 at 02:48:19PM +0200, Julien Cristau wrote:
> -UID: 41176
>
> Package: libelogind0
> Version: 241.3-1+debian1
> Severity: serious
>
> I wrote this in #934132 but that is being ignored so I'll repeat here.
Hello Julien,
> conflicting with systemd is doomed. The replacement of sysvinit with
> systemd was careful to keep both init systems co-installable, and I
note that:
① elogind is not part of the init system, only an add-on to enable
systemd-like Provides to get some GUI software to run
Package: libelogind0
Version: 241.3-1+debian1
Severity: serious
I wrote this in #934132 but that is being ignored so I'll repeat here.
I don't think it's reasonable to ship this package with C/R/P
libsystemd0.
I think it opens you (and, more importantly, users) up to issues like
#934491. Even
56 matches
Mail list logo
