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 days,
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 a
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 f
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.
>> * U
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 r
On Sun, 11 Jun 2023 at 22:17, Timo Röhling wrote:
>
> * Luca Boccassi [2023-06-10 19:54]:
> >I would caution to avoid interpreting clarifying questions being asked
> >as dissent. It's good to ask questions and clarify details about
> >corner cases, but I wouldn't automatically write them down as
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: systemd-sys
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.
Package: wnpp
Severity: wishlist
Owner: Nilesh Patra
* Package name: golang-github-tidwall-sjson
Version : 1.2.5-1
Upstream Author : Josh Baker
* URL : https://github.com/tidwall/sjson
* License : Expat
Programming Lang: Go
Description : Set JSON values
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 2023-06-27 16:58 +0200, Moritz Mühlenhoff wrote:
> Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca:
> > Hey Moritz,
> >
> > On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> > > I think this should rather be applied early after the Bookworm
> > > release (and ideally we can also f
Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca:
> Hey Moritz,
>
> On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> > I think this should rather be applied early after the Bookworm
> > release (and ideally we can also finish off the necessary testing
> > and add -fstack-clash-protec
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 an
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 daemon
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 o
On Mon, 26 Jun 2023 at 20:33, Aurelien Jarno wrote:
>
> On 2023-06-09 16:39, Thorsten Glaser wrote:
> > In particular I would, at the same time, like the baseline lowered
> > to i586 again. It was raised mostly for multimedia stuff, and it’s
> > now justifyable to ask people to use amd64 or armhf
18 matches
Mail list logo
