Hi,
On 02.12.19 00:20, Simon McVittie wrote:
>> In that particular case, the user session must be available to allow
>> activation of gsettingsd via dbus
> There is no such thing as gsettingsd. Presumably you mean dconf-service
> (which is conceptually one of many backends, although in practice
Hi,
On 02.12.19 00:07, Uoti Urpala wrote:
> In short: there is little to no worthwhile work being done on any
> alternatives to systemd. What is happening is some people trying to
> keep sysvinit working to about the level it did in 2014, while doing
> very little fundamental development to the
On Sun, 2019-12-01 at 18:43 -0500, Sam Hartman wrote:
> > > > > > "Uoti" == Uoti Urpala writes:
>
> Uoti> IMO encouragement for supporting alternative systems could be
> Uoti> reasonable, but only for actual new innovation; maintainers
> Uoti> should be explicitly permitted to remove
Hi!
I've been busy late yesterday and today, and not been able to reply
to some of the questions presented. I've got an early flight in a few
hours, so I'm unable to finish the draft reply I've started but which
I plan to send tomorrow (Monday). Sorry about this, but the rushed
timeline is not
> "Uoti" == Uoti Urpala writes:
Uoti> IMO encouragement for supporting alternative systems could be
Uoti> reasonable, but only for actual new innovation; maintainers
Uoti> should be explicitly permitted to remove any existing sysvinit
Uoti> scripts and refuse addition of
Hi,
On 01.12.19 23:24, Simon McVittie wrote:
> dbus-user-session is not, and probably will not be, usable on non-systemd
> systems. If per-user service managers other than `systemd --user` exist
> and can be configured to provide equivalent semantics, I'd be happy
> to review the necessary
Antonio Terceiro wrote:
> However, as with any piece of software, systemd doesn't and won't ever cover
> all use cases. It should be possible for people to use other init it they
> choose so, for whatever reason. How well those would work should depend only
> on
> the effort of those interested
On Sun, 01 Dec 2019 at 22:14:06 +0100, Laurent Bigonville wrote:
> It's bin:libpam-systemd that pulls bin:systemd-sysv (the package that makes
> systemd the init on the system), not bin:systemd. Here it's dbus-user-session
> that pulls it because it needs a logind (dunno if it works with elogind)
On Sun, 01 Dec 2019 at 22:02:31 +0100, Simon Richter wrote:
> In that particular case, the user session must be available to allow
> activation of gsettingsd via dbus
There is no such thing as gsettingsd. Presumably you mean dconf-service
(which is conceptually one of many backends, although in
On Sun, 01 Dec 2019 at 11:13:46 -0800, Russ Allbery wrote:
> Simon Richter writes:
> > Right, but the dependency chain is there to make sure the package is
> > usable on systemd systems
>
> My recollection is that these dependencies are mostly about either making
> sure user sessions are
Simon Richter mailto:sjr%40debian.org>> wrote:
> On 01.12.19 02:54, Russ Allbery wrote:
>
> >> Russ> Could you provide some more information about what your
> >> Russ> concern is here? libsystemd-dev depends only on libsystemd0,
> >> Russ> which has a pretty tiny list of dependencies
* Kurt Roeckx [2019-12-01 20:31]:
> F: Choice 1: Focus on systemd to promote standardization and
> cross-distribution cooperation
...
> I'm thinking about renaming F to just "Focus on systemd", to make
> it shorter. I'm not sure how devotee is going to like wrapping
> long lines.
Could you put
> "Bdale" == Bdale Garbee writes:
Bdale> Kurt Roeckx writes:
>> I'm thinking about renaming F to just "Focus on systemd", to make
>> it shorter. I'm not sure how devotee is going to like wrapping
>> long lines.
Bdale> Not sure I "get a vote" on this, but that would work
Hi,
On 01.12.19 20:13, Russ Allbery wrote:
>> Right, but the dependency chain is there to make sure the package is
>> usable on systemd systems, i.e. we'd have to accept a regression for the
>> systemd case in order to facilitate the non-systemd case, which is what
>> we don't want, or live with
Kurt Roeckx writes:
> I'm thinking about renaming F to just "Focus on systemd", to make
> it shorter. I'm not sure how devotee is going to like wrapping
> long lines.
Not sure I "get a vote" on this, but that would work fine for me.
The text should adequately elucidate the objectives, so trying
FYI, see
https://hartmans.livejournal.com/99642.html
for my attempt at a voting guide on the proposals currently on the
ballot.
On Sun, Dec 01, 2019 at 11:48:42AM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Withdrawing Proposal C; Option Ordering; CFV
> Timing"):
> > The reason I didn't reorder it yet, is because it's talked about
> > like that. But I guess I can just reorder it on the page, keep the
> > letter
Simon Richter writes:
> Right, but the dependency chain is there to make sure the package is
> usable on systemd systems, i.e. we'd have to accept a regression for the
> systemd case in order to facilitate the non-systemd case, which is what
> we don't want, or live with unrelated packages
Hi Russ,
On 01.12.19 18:16, Russ Allbery wrote:
>> https://lists.debian.org/debian-devel/2019/08/msg00278.html
> This is a point that Ian's proposal specifically addresses by accepting
> the possibility that packages will be installable but not usable on
> non-systemd systems in order to avoid
Hi Adam,
On 12/1/19 12:24 AM, Adam Borowski wrote:
> * there's a lot of use cases where systemd fails[1]. This makes it unfit
> for being the sole init+rc of an universal operating system.
I assume you've opened bugs for all those cases?
If I understand the problems you're mentioning right,
Simon Richter writes:
> That was a thread I started on debian-devel:
> https://lists.debian.org/debian-devel/2019/08/msg00278.html
> The resolution of that thread seemed to be that people were mostly fine
> with the dependency chain because every decision in the path makes
> sense, even if the
First of all, I would like to thank those who took the time to make proposals.
This is a very draining issue, and I thought more than twice about saying
something about it publicly at all. I hope that this is useful.
My position
---
I think systemd is better than anything that came
On 01/12/19 at 11:48 +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Withdrawing Proposal C; Option Ordering; CFV
> Timing"):
> > The reason I didn't reorder it yet, is because it's talked about
> > like that. But I guess I can just reorder it on the page, keep the
> > letter but change the
> "Ian" == Ian Jackson writes:
Ian> It seems to me that if improvements to G (say) become available
Ian> and are acceptable to the proposer, they should be on the
Ian> ballot, probably instead of the existing G. Because of
Ian> ambiguity in the constitution (sorry) it is not
We have had two proposals appear very recently. At least G seems to
me like it needs some work on the text and there are comments about F
floating about.
It seems to me that if improvements to G (say) become available and
are acceptable to the proposer, they should be on the ballot, probably
Kurt Roeckx writes ("Re: Withdrawing Proposal C; Option Ordering; CFV Timing"):
> The reason I didn't reorder it yet, is because it's talked about
> like that. But I guess I can just reorder it on the page, keep the
> letter but change the number.
Yes, please, do that.
Ian.
--
Ian Jackson
Thibaut Paumard writes ("Re: Question Under Proposal D: Compile Time Option"):
> I think the right fix would be to compile the package twice as "foo"
> (for the systemd version) and "foo-non-systemd".
>
> Another option would be to ship both versions in package "foo" and
> decide at runtime which
Hi,
On 01.12.19 10:06, Martin Michlmayr wrote:
> So there's a lot about proposal B that I like, but at the end of the
> day the proposal doesn't sound that different to the status quo.
> While it says systemd, there's no 100% commitment (there's no clear
> preference over Debian kludges for
On 01.12.19 02:54, Russ Allbery wrote:
>> Russ> Could you provide some more information about what your
>> Russ> concern is here? libsystemd-dev depends only on libsystemd0,
>> Russ> which has a pretty tiny list of dependencies and shouldn't
>> Russ> require that systemd be
Ian Jackson writes ("Re: Proposal: Reaffirm our commitment to support
portability and multiple implementations"):
> I think your proposal would work well as a preamble to many of the
> other options, notably mine and Dmitry's.
I've read the rest of the thread now. I think Adam Borowski's ideas
Guillem Jover writes ("Proposal: Reaffirm our commitment to support portability
and multiple implementations"):
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
I really like much of what you write in your proposal.
However, unfortunately, I
* Moritz Mühlenhoff [2019-11-30 11:48]:
> - Less ambigious, C only talks about service units and preferring other
> facilities "if they have clear and obvious advantages" (but we have no
> good method to clarify whether e.g. systemd-sysusers fulfills that over
> adduser), while F actively
* Sean Whitton [2019-11-29 17:52]:
> I would be grateful for an informal summary of why proposal F is
> thought to be needed on the ballot in addition to proposal C. What
> is thought not captured well by Sam's text, but is thought to be
> captured well by Martin's text?
I'm sorry for the
33 matches
Mail list logo
