Dear Debian developers, maintainers etc.
I use Debian for many years. My primary and only installation for work
is unstable installed in 2003 and i updated this one *many times*. I
love Debian because of freedom from more points of view.
One PoV is possibility to choose software component which
Hi,
I see that network-manager 1.28.0-2 has been uploaded, with (inter alia)
the following changelog entry:
* Demote libpam-systemd to Recommends.
This allows users to use and experiment with other init systems. Such a
setup is neither tested nor fully supported and users need to be aware
Hello,
On Mon 28 Dec 2020 at 12:24AM +01, gregor herrmann wrote:
> On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:
>
>> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
>> > My reasoning is that init scripts are the end goal, and that elogind is
>> > just a symptom of that end
> "Russ" == Russ Allbery writes:
Russ> We do drop features all the time between stable releases,
Russ> though, and generally that too is at the maintainer's
Russ> discretion. The package maintainer's normal obligation in
Russ> Debian isn't to keep everything working that
Sam Hartman writes:
> The issue that came up in the policy discussion is that there may be
> implications for removing an init script. As an example upgrades may
> break. In the case of NetworkManager, you might find on an upgrade from
> buster to bullseye that you no longer have network
❦ 28 décembre 2020 10:32 -05, Sam Hartman:
> But for example, we have a rule that is fairly basic to our community
> that we don't break upgrades, or at least we try hard not to.
This is becoming harder and harder because we pile more and more choices
(init choice, initramfs choice, merged-usr
> "Russ" == Russ Allbery writes:
Russ> I think this clearly and unambiguously says that maintainers
Russ> can depend on unit support and drop init scripts from their
Russ> packages if they so choose, and that this choice only requires
Russ> as much justification as rejecting
Russ Allbery writes:
> I assumed that if option B won, some
> maintainers would drop init scripts, and therefore if folks wanted to
> maintain a set of working init scripts, they'd need to look at different
> options than ensuring they were incorporated into each package.
I agree, this was my
gregor herrmann writes:
> What surprises me in this discussion: My very broad summary of the GR
> result was "systemd is the top priority, other init systems are
> supported on a best-effort basis", and now I'm reading statements which
> sound to me like "looking into new/future/niche init
On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:
> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
> > My reasoning is that init scripts are the end goal, and that elogind is
> > just a symptom of that end goal, and that therefore talking about
> > elogind in isolation serves no
Hello Wouter,
On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
> My reasoning is that init scripts are the end goal, and that elogind is
> just a symptom of that end goal, and that therefore talking about
> elogind in isolation serves no purpose.
The GR specifically mentions elogind
Hi Sam,
On Sun, Dec 27, 2020 at 10:05:37AM -0500, Sam Hartman wrote:
> > "Wouter" == Wouter Verhelst writes:
> Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> >> I think that we should either decide that
> >>
> >> 1) NetworkManager should support elogind
> >>
> >> or
> "Wouter" == Wouter Verhelst writes:
Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
>> I think that we should either decide that
>>
>> 1) NetworkManager should support elogind
>>
>> or
>>
>> 2) That we haven't seen enough development
On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> I think that we should either decide that
>
> 1) NetworkManager should support elogind
>
> or
>
> 2) That we haven't seen enough development of alternatives to systemd
> and the project consensus on the GR has changed.
Personally,
Elana,
Thanks for passing this on.
On Mon, Dec 21, 2020 at 03:36:45PM -0800, Elana Hashman wrote:
> Less than 1% of users are installing sysvinit-core, with a steady
> downward trend.[1]
I accept that the number of users is small, although the figures referenced omit
users of openrc and runit.
Matthew writes:
> * We've talked about the burden already; there are people willing and
> able to help with this, and that offer remains good, be that by
> providing patches, MRs, help with bug reports on non-systemd systems,
> NMUs, or some other mechanism that Michael would prefer
I think
Hi,
On 21/12/2020 23:36, Elana Hashman wrote:
The maintainer, Michael Biebl, reached out to the tech-ctte privately. I
have summarized his reasoning for why he dropped support for elogind and
the init script that prompted this bug:
Thanks. There's little point trying to have this discussion
On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote:
>
> I caution folks from speculating too much on the maintainer's
> motivations and reasoning while they haven't yet had a chance to share
> their perspective on the bug. :)
>
> From what I can see reading through both #964139 and
Matthew Vernon writes:
> On 14/12/2020 21:56, Philip Hands wrote:
>
>> Could I just check if there's a point of common acceptability which both
>> sides of this discussion could live with?
>
> [...]
>
>> My suggestion for a mutually bearable solution would be that the
>> network-manager package
On Wed, 2020-12-16 at 14:46 +, Matthew Vernon wrote:
Not is it straightforwardly clear that "alternative init systems"
should in fact be interpreted to mean "alternative init systems (but
not
sysvinit)".
The GR text mostly seems to talk about *exploring* alternatives;
continuing to maintain
> "Matthew" == Matthew Vernon writes:
Matthew> On 15/12/2020 22:07, Sam Hartman wrote:
>>> However, Debian remains an environment where developers and
>>> users can explore and develop alternate init systems and
>>> alternatives to systemd features. Those interested in
On 14/12/2020 21:56, Philip Hands wrote:
Could I just check if there's a point of common acceptability which both
sides of this discussion could live with?
[...]
My suggestion for a mutually bearable solution would be that the
network-manager package could have its dependency on
On 15/12/2020 22:07, Sam Hartman wrote:
However, Debian remains an environment where developers and users can
explore and develop alternate init systems and alternatives to systemd
features. Those interested in exploring such alternatives need to
provide the necessary development and packaging
I had a great discussion with Mark Hindley about this issue a few months
ago.
I'd like to summarize what I said in that discussion as input to the TC.
But I'd also like to start out by reminding us all what we said in the
GR text that we agreed to.
As one of the contributors to that text, you
❦ 15 décembre 2020 11:14 GMT, Mark Hindley:
>> Okay, great, I now see a clearer argument in favour of dropping the init
>> script: enabling the maintainer to preemptively avoid dealing with bugs
>> which are likely to generate hostility, rather than just the idea that
>> there could be bugs
Hello,
On Tue 15 Dec 2020 at 11:14AM GMT, Mark Hindley wrote:
> Sean and Simon,
>
> On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote:
>> > In the cases where the regression was accidental, ideally, the answer
>> > would be someone calmly and politely offering a tested patch, but it
Sean and Simon,
On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote:
> > In the cases where the regression was accidental, ideally, the answer
> > would be someone calmly and politely offering a tested patch, but it
> > sadly seems equally likely to result in hostility, and I think it's
On Tue, Dec 15, 2020 at 09:51:56AM +, Simon McVittie wrote:
> On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote:
> > Could I just check if there's a point of common acceptability which both
> > sides of this discussion could live with?
> >
> > libpam-systemd |
On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote:
> Could I just check if there's a point of common acceptability which both
> sides of this discussion could live with?
>
> libpam-systemd | network-manager-nonsystemd
Presumably this is an optimized form of what we perhaps conceptually
Sean Whitton writes:
> It is difficult to think further about this without input from the
> maintainer as to how much this was a part of his motivation, and what
> experiences he has had led him to think in that way.
Hi All,
Could I just check if there's a point of common acceptability which
Hello,
On Mon 14 Dec 2020 at 10:58AM GMT, Simon McVittie wrote:
> On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote:
>
>> Participants in the thread who have argued on that side of the
>> discussion seem to implicitly rely on the idea that a package maintainer
>> is responsible for
On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote:
> The dependency issue is more challenging.
As I said earlier in the thread, if we don't want to overrule on the
logind dependency, then I don't think overruling on the init script
would make any sense (whereas overruling on the logind
Hello Simon and others,
On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote:
> If we are unable to use particular system services (in this case NM) with
> a particular non-default init system without putting extra responsibility
> on the maintainers of those system services, then I think
Josh,
On Mon, Nov 30, 2020 at 04:24:28PM -0800, Josh Triplett wrote:
> If (hypothetically) network-manager upstream
> decided to remove those legacy fallbacks, the maintainer would then be
> in a position of either:
But that is not what this particular discussion is about. Personally, I have no
On Mon, 30 Nov 2020 10:55:44 + Mark Hindley wrote:
> On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote:
> > On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> > > #921012 is about changing network-manager to Depend upon "default-logind |
> > > logind" rather than
Hi,
On 29/11/2020 16:59, Simon McVittie wrote:
Some procedural points, without going into the merits of the technical
committee doing as you ask or not:
Broadly, I expect the TC to know their procedural stuff better than I
do, but I'll try and answer your points :)
On Wed, 18 Nov 2020 at
Simon,
Thanks for your clear and insightful comments.
On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote:
> On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> > #921012 is about changing network-manager to Depend upon "default-logind |
> > logind" rather than
On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> #921012 is about changing network-manager to Depend upon "default-logind |
> logind" rather than libpam-systemd
This is a change that is *sometimes* appropriate, but sometimes not,
depending on what facility the dependent package
On Sat, 21 Nov 2020 at 10:47:17 +0200, Wouter Verhelst wrote:
> On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote:
> > 1) poor user experience - a package of initscripts would clutter
> > /etc/init.d/ with a huge number of files (most of which would be no use to
> > the user)
>
> This
On Thu, 19 Nov 2020 at 21:04:00 -0800, Elana Hashman wrote:
> It would be much appreciated if Michael Biebl or another maintainer from
> the Utopia team could add some context here.
Most of the people in the pkg-utopia team are not active contributors to
most of its packages, so I don't think
On Thu, 19 Nov 2020 at 11:40:20 +, Ian Jackson wrote:
> My view is
> that the behaviour seen in #921012 and #964139 is an outrage
I don't think this is constructive, and if a package's maintainer doesn't
want to enter into conversations, this doesn't seem like an approach
that will change
Some procedural points, without going into the merits of the technical
committee doing as you ask or not:
On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> I invite the technical committee to rule that:
> * The network-manager init script should be restored
> * Network-manager should
On Sat, 21 Nov 2020 at 10:42:04 +0100, Vincent Bernat wrote:
> I don't think this is very common. Init scripts are very specific to a
> distribution. A Debian init script cannot be used for Redhat. A SUSE
> init script does not work with Redhat. I find doubtful that the
> compatibility would be
❦ 19 novembre 2020 09:04 GMT, Matthew Vernon:
> 3) many upstreams (esp. those who support BSD) ship a sysvinit file,
> again making the daemon (source at least) package the natural place to
> keep it.
I don't think this is very common. Init scripts are very specific to a
distribution. A Debian
On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote:
> [I don't need a CC, thanks]
> Hi,
>
> > I know it was mentioned back in the day, but trying to re-ask it now:
> > Wouldn't it be possible to ship init scripts for compatibility purposes
> > from a sysvinit (or maybe a
On Thu, Nov 19, 2020 at 04:20:46PM -0800, Tianon Gravi wrote:
>
> On Wed, 18 Nov 2020 at 23:33, Josh Triplett wrote:
> > Any inclusion of work into a package necessitates *some* amount of
> > development and packaging resources by the maintainer of that package.
> > Even if someone else offers
(Going to leave my own opinions on the underlying discussion here
aside, but wanted to highlight/echo this bit:)
On Wed, 18 Nov 2020 at 23:33, Josh Triplett wrote:
> Any inclusion of work into a package necessitates *some* amount of
> development and packaging resources by the maintainer of that
On Thu, 19 Nov 2020 13:04:56 -0700 Sean Whitton
wrote:
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > First, as a point of order (for which some authoritative guidance from
> > the Secretary, CCed, would potentially prove useful): while the
> > technical committee is empowered to
On Thu, 19 Nov 2020 12:00:45 -0700 Sean Whitton
wrote:
> Hello,
>
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > I'd also like to address one other issue here. It would be easy to
> > hypothesize, at this point, that some additional communication (or more
> > verbose
Hello,
On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> First, as a point of order (for which some authoritative guidance from
> the Secretary, CCed, would potentially prove useful): while the
> technical committee is empowered to handle various types of disputes (up
> to and including
Hello,
On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would
Hello,
On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would
Hi,
On Wed, Nov 18, 2020 at 11:33 PM Josh Triplett wrote:
>
> I do not believe it falls within the scope of the technical committee
> to override a decision already decided by a project-wide GR
In the State of California we follow such a strict interpretation of
ballot measures. While
1. Basic principles
Josh Triplett writes:
> I do not believe it falls within the scope of the technical
> committee to override a decision already decided by a project-wide
> GR,
No-one is asking the TC to override the GR. In fact, Matthew is
asking the TC to *implement* the GR.
> or to
[I don't need a CC, thanks]
Hi,
I know it was mentioned back in the day, but trying to re-ask it now:
Wouldn't it be possible to ship init scripts for compatibility purposes
from a sysvinit (or maybe a sysvinit-support) package? This would be the
inverse of what happened back when systemd was
On Wed, 18 Nov 2020 17:33:26 + Matthew Vernon wrote:
> This bug report relates specifically to bugs in the network-manager
> package (#921012, #964139) but has broader implications, particularly
> around what it means to "support the efforts of developers"[0] working
> on support for
On 18.11.20 18:33, Matthew Vernon wrote:
> Package: tech-ctte
> Control: block 921012 by -1
> Control: block 964139 by -1
> X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk
>
> Dear Technical Committee,
>
> This bug report relates specifically to bugs in the network-manager
> package
Hi,
On Wed, Nov 18, 2020 at 10:21 AM Matthew Vernon wrote:
>
> I invite the technical committee to rule that:
What a great read! This message must be among the best prepared, and
most polite, to come before the committee.
Kind regards,
Felix Lechner
Package: tech-ctte
Control: block 921012 by -1
Control: block 964139 by -1
X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk
Dear Technical Committee,
This bug report relates specifically to bugs in the network-manager
package (#921012, #964139) but has broader implications,
59 matches
Mail list logo
