Quoting Vincent Lefevre (2024-03-06 12:17:55)
> On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:
> > Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> > > However it's true that some packages are installed before that, at the
> > > debootstrap stage, and I guess debootstrap doesn't honor
On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:
> Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> > However it's true that some packages are installed before that, at the
> > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?
>
> Correct. This is tracked as
Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> On 05/03/2024 9:22 pm, Vincent Lefevre wrote:
> > On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:
> >> For example, when I implemented libuuid, if you want to create a huge
> >> number of UUID's very quickly, because you're a large enterprise
>
On 05/03/2024 9:22 pm, Vincent Lefevre wrote:
On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:
For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:
> For example, when I implemented libuuid, if you want to create a huge
> number of UUID's very quickly, because you're a large enterprise
> resource planning application, the the uuidd daemon will allow
> multiple processes to request "chunks" of
Hi,
On 1/16/24 03:55, Simon McVittie wrote:
I would personally like to see *more* privilege separation across IPC
boundaries rather than less, if that can reduce the total attack surface
of the setuid/setcap executables in the trusted computing base.
Yes, however there is a downside to
Roger Lynn writes:
> On 15/01/2024 18:00, Russ Allbery wrote:
>> When you have the case of an application that optionally wants to do foo,
>> a shared library that acts as a client, and a daemon that does foo, there
>> are three options:
>>
>> 1. Always install the shared library and daemon even
On 15/01/2024 18:00, Russ Allbery wrote:
> When you have the case of an application that optionally wants to do foo,
> a shared library that acts as a client, and a daemon that does foo, there
> are three options:
>
> 1. Always install the shared library and daemon even though it's an
>
On Mon, 15 Jan 2024 at 19:59:22 +0100, Johannes Schauer Marin Rodrigues wrote:
> Just today I had a case where I was building something innocent and suddenly I
> had an init system installed because:
>
> libgtk-3-dev -> libgtk-3-common -> dconf-gsettings-backend -> dconf-service \
> ->
Hi,
Quoting Ansgar (2024-01-07 20:39:57)
> I would like to extend Debian Policy on libraries depending on services
> (daemons) that they can speak to.
>
> Let me bring to examples, one made up,, one for which I filed a bug
> recently. But as far as I can tell this question comes up from time to
On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote:
> "Theodore Ts'o" writes:
> > I'll argue that best practice is that upstream [should] make the shared
> > library useful *without* the daemon
Is the argument here that any design that separates into clients and a
non-optional server (for
On 15/01/24 18:58, Russ Allbery wrote:
When you have the case of an application that optionally wants to do foo,
a shared library that acts as a client, and a daemon that does foo, there
are three options:
From the point of view a Debian package there are four options:
Depends:, Recommends:,
"Theodore Ts'o" writes:
> I'll argue that best practice is that upstream show make the shared
> library useful *without* the daemon, but if the daemon is present,
> perhaps the shared library can do a better job.
Eh, I think this too depends on precisely what the shared library is for.
The
On Mon, Jan 08, 2024 at 11:18:09AM +, Simon McVittie wrote:
> On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote:
> > Maybe the question is also a bit .. "it depends".
> ...
> > So that users actually likely get a system that works?
>
> I think the fact that we argue about this every
On 2024-01-08 09:57:16 +0100 (+0100), Dylan Aïssi wrote:
[...]
> Please don't do that. At least one pipewire module depends on libpulse0
> (libpipewire-module-pulse-tunnel from the libpipewire-0.3-modules package).
> But, pulseaudio is useless in this case that means it will be unnecessarily
>
On 07/01/2024 19:39, Ansgar wrote:
> I would like to extend Debian Policy on libraries depending on services
> (daemons) that they can speak to.
Generally speaking, if an application is using a client-server model and
there's no technical requirement for the client and server to be running on
On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote:
> Maybe the question is also a bit .. "it depends".
...
> So that users actually likely get a system that works?
I think the fact that we argue about this every few years, with no simple
conclusion, is adequate evidence that the answer is
Hi,
Le dim. 7 janv. 2024 à 20:40, Ansgar a écrit :
>
> 1. libpulse0 & friends
> --
>
> libpulse0 is a client library for the Pulseaudio server. It doesn't do
> much without pulseaudio.
>
> Q: Should libpulse0 have Depends: pulseaudio?
Please don't do that. At least one
On 2024-01-07, Ansgar wrote:
> 1. libpulse0 & friends
> --
> If the answer is "yes", this would result in an application that can
> output audio via Pulseaudio or Jackd and linking the respective
> liubraries pulling in *both* Pulseaudio and Jackd (and possibly other
> sound
On 1/7/24 15:36, Jonas Smedegaard wrote:
Quoting Ansgar (2024-01-07 20:39:57)
I therefore think that libraries (be it classic C shared object
libraries or Python modules or others) should in general *not* have
Depends: or Recommends: relations on services (DBus services, DBus
itself, daemons,
Quoting Ansgar (2024-01-07 20:39:57)
> I therefore think that libraries (be it classic C shared object
> libraries or Python modules or others) should in general *not* have
> Depends: or Recommends: relations on services (DBus services, DBus
> itself, daemons, ...).
I thought this was already in
On January 7, 2024 7:39:57 PM UTC, Ansgar wrote:
>Hi,
>
>I would like to extend Debian Policy on libraries depending on services
>(daemons) that they can speak to.
>
>Let me bring to examples, one made up,, one for which I filed a bug
>recently. But as far as I can tell this question comes up
22 matches
Mail list logo
