tito via Dng - 30.07.23, 14:25:39 CEST:
> On Sun, 30 Jul 2023 11:27:04 +0200
>
> Martin Steigerwald <martin@???> wrote:
> > tito via Dng - 30.07.23, 10:10:31 CEST:
> > > > Here are some benefits:
> > > >
> > > > * Never again would some poor daemon upstream or package
> > > > maintainer
> > > > need to burdon him/herself with init scripts, run scripts, unit
> > > > files
> > > > and all that stuff. They already did us a favor by
> > > > creating/packaging
> > > > the daemon: They shouldn't have the further demands of startup
> > > > scaffolding.
> > >
> > > I still think that a debian policy to actively hand over the
> > > runit,init,openrc scripts if removed to orphan-* packages is the
> > > easier alternative and probably could be setup as debian still
> > > states that it supports init diversity. What do the people that
> > > is/was in debian about this proposal?
> >
> > Some maintainers in Debian already do this. See for example:
> >
> > Bug#1042082: Please take over udev SysV init script
> >
> > https://bugs.debian.org/1042082
> >
> > However if its about discussing init diversity (I'd love to have a
> > better word for this) in Debian (!), this is clearly not the list
> > that is likely to reach all of people who do the actually work.
> >
> > Debian-init-diversity -- Debian ecosystem init system diversity
> >
> > https://www.chiark.greenend.org.uk/mailman/listinfo/debian-init-dive
> > rsity
>
> I'm subscribed to that list so I could forward it over there.
> My problem with that is that I know nothing about
> the inner processes of debian and I'm not involved
> in debian packaging.
> As it seems to me that you are more experienced
> would you like to sponsor the proposal over there
> in the case you agree with it to some extent?

I am not sure whether a policy would really change much here, cause in
the end, people will notice in case a maintainer drops an init script,
and it can always be resurrected from the last version of the package
that had the script.

I maintain one Debian package, but I am neither a official Debian
Developer or Debian Maintainer. I bet efforts to make this an official
policy would detract resources better spend on making things work into
political discussions within Debian.

> > is the list for that. And yes, its not on official Debian infra
> > structure on purpose. But there Devuan *and* Debian developers and
> > developers working for both distributions communicate with one
> > another!
> >
> > For anyone who has a proposal, I bet its also good to bring in some
> > time and willingness to contribute in some way.
>
> Hope that thinking about the future of devuan is part of "some way".

It is some way, I bet. However as said, a case for a policy here needs
to have a strong benefit behind it in order to justify the efforts to
bring it through as a policy. I am not completely sure what would be
required here, cause I do not know the exact process of implementing
changes to the Debian Standards packaging policy. But I am pretty sure
it would be a considerable effort especially for the Debian/Devuan init
diversity team which is under-staffed anyway.

So to actually really bring this in as a policy I suggest you better be
prepared to dig yourself into Debian processes deep enough to be able to
actually help to drive implementing your idea as policy forward.

--
Martin