Ansgar Burchardt writes:
> Stuart Prescott writes:
>>> I find Priority: extra useful for at least transitional packages,
>>> detached debug symbols, and packages conflicting with packages of
>>> priority >= important (or maybe >= standard) that will continue to do
>>> so, say for example alterna
Package: debian-policy
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
For practical reasons, variables that are used to configure init scripts
behaviour are placed in separate files in /etc/default, as documented in
Policy §9.3.2.
The same is often applied to cron job
Hi,
Russ Allbery:
> Could you say more about why you think conflicting packages having a
> separate priority from optional is useful? When would people use that
> priority information, and how?
>
Let's assume that I have a large multiuser Debian system. I don't want to
be bothered by people requ
Your message dated Tue, 26 Aug 2014 09:38:43 -0700
with message-id <1409071123.4148.7.camel@chianamo>
and subject line developers-reference: removal of membership benefits
information
has caused the Debian Bug report #586186,
regarding developers-reference: mention DD certificates in "Goodies for
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Stuart Prescott writes:
>> Related to that: Given d-i/debootstrap are the main users, I think
>> having d-i ignore the priority of library packages already[1] is an
>> indication that allowing packages to depend on library packages with
>> lower
Russ Allbery writes:
> Ansgar Burchardt writes:
>> Stuart Prescott writes:
I find Priority: extra useful for at least transitional packages,
detached debug symbols, and packages conflicting with packages of
priority >= important (or maybe >= standard) that will continue to do
Matthias Urlichs writes:
> Russ Allbery:
>> Could you say more about why you think conflicting packages having a
>> separate priority from optional is useful? When would people use that
>> priority information, and how?
> Let's assume that I have a large multiuser Debian system. I don't want
>
Le Mon, Aug 25, 2014 at 06:06:01AM +0200, Johannes Schauer a écrit :
>
> please consider adding "nodoc" as a possible DEB_BUILD_OPTIONS value to
> § 4.9.1 [1].
>
> The value "nodoc" or "nodocs" is currently used in 72 source packages
> according to [2]. Documenting "nodoc" in policy would avoid t
Charles Plessy writes:
> I think that it is a good idea. Here is a draft patch.
> When writing this patch, I became unsure if “*-doc” packages are the
> best description for the binary packages that will not be built. Should
> it be any package in the “documentation” section instead ? Or shou
Le Tue, Aug 26, 2014 at 09:55:29AM +0200, Tanguy Ortolo a écrit :
>
> For practical reasons, variables that are used to configure init scripts
> behaviour are placed in separate files in /etc/default, as documented in
> Policy §9.3.2.
>
> The same is often applied to cron jobs as well, for the sa
Hi,
Russ Allbery:
> > Let's assume that I have a large multiuser Debian system. I don't want
> > to be bothered by people requesting this or that package all the time,
> > so I simply install everything that's of priority
> Has anyone actually done this in the last five years? I'm extremely
> d
Le Wed, Aug 27, 2014 at 12:43:16AM +0200, Matthias Urlichs a écrit :
> Russ Allbery:
> >
> > Do you actually do this? Is optional actually conflict-free? I'm pretty
> > sure it isn't.
> >
> No, it's not. But I'd like it to be.
>
> However, if a consensus should emerge that it's too much hassl
Ansgar Burchardt wrote:
> Russ Allbery writes:
>> In some cases, it can change maintenance decisions.
>
> Does this differ much from packages being picked up by other commonly
> installed software? Say GNOME starting to depend on my small library
> which suddenly raises from ~100 to 5+ report
13 matches
Mail list logo
