Andreas Henriksson writes:
> If you want me to take suggestions like coordination seriously then
> please consider adressing https://bugs.debian.org/934463 soon or admit
> that sysvinit maintenance lacks the resources to do coordinated
> transitions. Dropping things and letting people pick them
> "Sam" == Sam Hartman wrote:
> "Simon" == Simon Richter writes:
> "Sam" == On 6/29/23 01:56, Sam Hartman wrote:
Sam> It also seems a bit strange to require more from the maintainer
Sam> when they are dropping an init script than we would if a
Sam> maintainer started depending on
Hi,
On 6/29/23 04:49, Helmut Grohne wrote:
* Package A 1.0-1 is installed providing file F.
* File F is moved to package B as of package A 1.0-3.
* User installs package B, which replaces the file in package A.
* User uninstalls package B.
F is now gone, even though it's supposed to be
On Thu, 29 Jun 2023 at 13:34, Helmut Grohne wrote:
>
> Hi Bas,
>
> On Thu, Jun 29, 2023 at 08:19:51AM +0200, Sebastiaan Couwenberg wrote:
> > On 6/28/23 21:49, Helmut Grohne wrote:
> > > Debian GIS Project
> > > postgis
> > > qgis
> >
> > Why is postgis on this list?
> >
> > $ grep -c
On 6/29/23 12:32, Helmut Grohne wrote:
On Thu, Jun 29, 2023 at 08:19:51AM +0200, Sebastiaan Couwenberg wrote:
On 6/28/23 21:49, Helmut Grohne wrote:
Debian GIS Project
postgis
qgis
Why is postgis on this list?
$ grep -c Replaces debian/control*
debian/control:0
Hi Bas,
On Thu, Jun 29, 2023 at 08:19:51AM +0200, Sebastiaan Couwenberg wrote:
> On 6/28/23 21:49, Helmut Grohne wrote:
> > Debian GIS Project
> > postgis
> > qgis
>
> Why is postgis on this list?
>
> $ grep -c Replaces debian/control*
> debian/control:0
> debian/control.in:0
On 6/28/23 21:49, Helmut Grohne wrote:
Debian GIS Project
postgis
qgis
Why is postgis on this list?
$ grep -c Replaces debian/control*
debian/control:0
debian/control.in:0
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750
Michael Biebl writes:
> While I find this discussion really interesting, is this really relevant
> for orphan-sysvinit-scripts? After all, it doesn't ship any conffiles in
> /etc, i.e. it doesn't take over any (conf)files from packages that
> dropped their initscript.
> Have you actually looked
> "Simon" == Simon Richter writes:
>> It also seems a bit strange to require more from the maintainer
>> when they are dropping an init script than we would if a
>> maintainer started depending on a feature like socket activation
>> such that their packkage simply would not
Hi,
On 6/29/23 01:56, Sam Hartman wrote:
Russ> This feels like exactly the kind of problem that normally
Russ> Debian goes to some lengths to avoid creating, but it sounds
Russ> like several commenters here don't think the effort is worth
Russ> it?
Normally, Debian
> "Russ" == Russ Allbery writes:
Russ> I think the open question is whether we're happy to just break
Russ> init scripts in unstable, since that migration path means
Russ> there will always be a window where a fully-upgraded unstable
Russ> system has no init script for a
On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote:
> Debian Policy no longer requires that packages which provide a systemd
> .service
> file also provide an initscript. This permits maintainers who so wish to
> remove
> initscripts from their packages. However, initscripts remain
Am 27.06.23 um 19:31 schrieb Russ Allbery:
Simon Richter writes:
The only thing we actually need is a versioned Replaces that allows
orphan-sysvinit-scripts to take over ownership of the conffile.
Conflicts is unneeded here, and the daemon package does not need to
declare any relationship.
Hello Thomas Goirand,
On Wed, Jun 28, 2023 at 10:01:13AM +0200, Thomas Goirand wrote:
> On 6/27/23 17:45, Andreas Henriksson wrote:
> > Dropping things and letting people pick them up if they
> > think they are still useful seems to be the only practical way forward.
>
> It's not. As written by
On Wed, Jun 28, 2023 at 10:01:13AM +0200, Thomas Goirand wrote:
> It's not. As written by Russ in this thread, filling a bug against
> orphan-sysvinit-scripts so it takes over the abandoned script is. I wouldn't
> mind seeing this mandatory, and written in the policy.
I do. This also does not
On Wed, 28 Jun 2023, 06:31 Paul Wise, wrote:
> On Tue, 2023-06-27 at 09:36 +0100, Luca Boccassi wrote:
>
> > That has been implemented a long time ago, services can set
> > ProtectProc= so that processes run with hidepid:
> >
> >
>
On 6/27/23 17:45, Andreas Henriksson wrote:
Dropping things and letting people pick them up if they
think they are still useful seems to be the only practical way forward.
It's not. As written by Russ in this thread, filling a bug against
orphan-sysvinit-scripts so it takes over the abandoned
On Tue, 2023-06-27 at 21:05:57 -0700, Russ Allbery wrote:
> Simon Richter writes:
> > On 6/28/23 02:31, Russ Allbery wrote:
> >> Normally Conflicts is always added with Replaces because otherwise you can
> >> have the following situation:
>
> >> * Package A version 1.0-1 is installed providing
* Russ Allbery , 2023-06-27 23:19:
for some reason I thought we normally always combine Replaces with
Breaks or Conflicts even for other cases.
There is a good reason.
Consider the following scenario:
* Package A 1.0-1 is installed providing file F.
* File F is moved to package B as of
Hi,
On 6/28/23 15:19, Russ Allbery wrote:
Yeah, I knew that part, but for some reason I thought we normally always
combine Replaces with Breaks or Conflicts even for other cases. Maybe I
just made that up and confused myself.
No, we just have very few use cases for Replaces alone these
Simon Richter writes:
> On 6/28/23 13:05, Russ Allbery wrote:
>> In that case, I don't actually know why we usually use Conflicts with
>> Replaces. Maybe we don't really need to?
> Replaces+Conflicts together has a special meaning, that is used for
> replacing a package completely in an atomic
Hi,
On 6/28/23 13:05, Russ Allbery wrote:
In that case, I don't actually know why we usually use Conflicts with
Replaces. Maybe we don't really need to?
Replaces+Conflicts together has a special meaning, that is used for
replacing a package completely in an atomic operations, such as when
On Tue, 2023-06-27 at 09:36 +0100, Luca Boccassi wrote:
> That has been implemented a long time ago, services can set
> ProtectProc= so that processes run with hidepid:
>
> https://freedesktop.org/software/systemd/man/systemd.exec.html#ProtectProc=
Thats opt-in and for services only, there are
Simon Richter writes:
> On 6/28/23 02:31, Russ Allbery wrote:
>> Normally Conflicts is always added with Replaces because otherwise you can
>> have the following situation:
>> * Package A version 1.0-1 is installed providing file F.
>> * File F is moved to package B as of package A 1.0-3.
>> *
Hi,
On 6/28/23 02:31, Russ Allbery wrote:
Normally Conflicts is always added with Replaces because otherwise you can
have the following situation:
* Package A version 1.0-1 is installed providing file F.
* File F is moved to package B as of package A 1.0-3.
* User installs package B, which
Simon Richter writes:
> The only thing we actually need is a versioned Replaces that allows
> orphan-sysvinit-scripts to take over ownership of the conffile.
> Conflicts is unneeded here, and the daemon package does not need to
> declare any relationship. They can use
> Depends:
Hi Ansgar,
On 6/27/23 01:45, Ansgar wrote:
[systemd service wrapper provided by init]
I think sysvinit maintainers looked at such ideas in the past, but
weren't capable to get it to work. That might be a blocker for such
approaches. There was also a GSoC project in 2012 and some other work.
Hello all,
On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote:
> Hello friends and colleagues,
[...]
> To avoid breakage of existing systems and facilitate ongoing support for
> non-systemd inits, I would like to establish a consensus for
>
> - stating that initscripts remain useful.
On 6/25/23 16:15, Mark Hindley wrote:
Hello friends and colleagues,
Debian Policy no longer requires that packages which provide a systemd .service
file also provide an initscript. This permits maintainers who so wish to remove
initscripts from their packages. However, initscripts remain used
On Mon, 26 Jun 2023 at 20:04:11 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> > started as root and dropped privileges to some other uid, that permanently
> > restricts its ability to read information out of its own /proc, which is
> > not always desirable. If the
On Tue, 27 Jun 2023 at 01:04, nick black wrote:
>
> Simon McVittie left as an exercise for the reader:
> > started as root and dropped privileges to some other uid, that permanently
> > restricts its ability to read information out of its own /proc, which is
> > not always desirable. If the
On Tue, 27 Jun 2023 at 04:10, Paul Wise wrote:
>
> On Mon, 2023-06-26 at 20:04 -0400, nick black wrote:
>
> > furthermore, this is only true when procfs is mounted with a
> > nonzero hidepid, right?
>
> I note that systemd does not support non-zero hidepid, so
> procfs hidepid will always be off
On Mon, 2023-06-26 at 20:04 -0400, nick black wrote:
> furthermore, this is only true when procfs is mounted with a
> nonzero hidepid, right?
I note that systemd does not support non-zero hidepid, so
procfs hidepid will always be off on systemd based systems:
Simon McVittie left as an exercise for the reader:
> started as root and dropped privileges to some other uid, that permanently
> restricts its ability to read information out of its own /proc, which is
> not always desirable. If the daemon starts up unprivileged, then it can
i assume by "its own
On Monday, June 26, 2023 2:02:24 PM EDT Bastian Blank wrote:
> On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:
> > > Less prone to errors than a manual process might be to watch
> > > automatically where legacy startup scripts disappear anyway; it's not
> > > that complicated to
Bastian Blank writes:
> On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:
>>> Less prone to errors than a manual process might be to watch
>>> automatically where legacy startup scripts disappear anyway; it's not
>>> that complicated to do. People tend to forget things.
>> That
On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:
> > Less prone to errors than a manual process might be to watch
> > automatically where legacy startup scripts disappear anyway; it's not
> > that complicated to do. People tend to forget things.
>
> That sounds reasonable. It
On Monday, June 26, 2023 12:45:11 PM EDT Ansgar wrote:
> On Sun, 2023-06-25 at 11:15 -0700, Russ Allbery wrote:
> > Bastian Blank writes:
> > > Sorry no. Please add a conversion layer that adopts service and
> > > maybe other systemd units to initrc if you care about it. This is
> > > what
On Sun, 2023-06-25 at 11:15 -0700, Russ Allbery wrote:
> Bastian Blank writes:
> > Sorry no. Please add a conversion layer that adopts service and
> > maybe other systemd units to initrc if you care about it. This is
> > what systemd does to adopt existing init scripts, so you can do the
> >
On Mon, 26 Jun 2023 at 15:03:51 +0900, Simon Richter wrote:
> On 6/25/23 23:15, Mark Hindley wrote:
> > The most recent proposal[6] for updating the Policy with a requirement to
> > use
> > tmpfiles.d(5) states
>
> > "Init systems other than ``systemd`` should allow providing the same
> >
Hi,
On 6/25/23 23:15, Mark Hindley wrote:
The most recent proposal[6] for updating the Policy with a requirement to use
tmpfiles.d(5) states
"Init systems other than ``systemd`` should allow providing the same
functionality as appropriate for each system, for example managing the
Mark Hindley writes:
> Debian Policy no longer requires that packages which provide a systemd
> .service file also provide an initscript. This permits maintainers who
> so wish to remove initscripts from their packages. However,
> initscripts remain used and useful[1], and uncoordinated removal
Bastian Blank writes:
> On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote:
>> To avoid breakage of existing systems and facilitate ongoing support
>> for non-systemd inits, I would like to establish a consensus for
>> - stating that initscripts remain useful.
>> - requiring a
Mark Hindley writes:
> The most recent proposal[6] for updating the Policy with a requirement
> to use tmpfiles.d(5) states
> "Init systems other than ``systemd`` should allow providing the same
> functionality as appropriate for each system, for example managing the
> directories from the
On Sun, 25 Jun 2023 at 15:21, Mark Hindley wrote:
> "Init systems other than ``systemd`` should allow providing the same
> functionality as appropriate for each system, for example managing the
> directories from the init script shipped by the package."
>
> This creates an inconsistency
On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote:
> To avoid breakage of existing systems and facilitate ongoing support for
> non-systemd inits, I would like to establish a consensus for
> - stating that initscripts remain useful.
> - requiring a coordinated transition of any
Hello friends and colleagues,
Debian Policy no longer requires that packages which provide a systemd .service
file also provide an initscript. This permits maintainers who so wish to remove
initscripts from their packages. However, initscripts remain used and useful[1],
and uncoordinated removal
47 matches
Mail list logo
