Re: dpkg: scripts/mk: add fragment to preen env

2023-01-29 Thread Konstantin Demin
Hi! Many thanks for your work! > diff --git a/scripts/mk/buildenv.mk b/scripts/mk/buildenv.mk > new file mode 100644 > index 0..dc6f61428 > --- /dev/null > +++ b/scripts/mk/buildenv.mk > @@ -0,0 +1,29 @@ > +# This Makefile fragment (since dpkg 1.22.0) sanitizes the environment > +#

Re: Terminology changes for update-alternatives

2023-01-29 Thread James Addison
On Sun, Jan 29, 2023 at 06:00:51AM +0100, Guillem Jover wrote: > I've been pondering about other options, and I think the concept that > seems to describe best the relationship is akin a planet and its moon > or satellite orbiting around it and being pulled along. But satellite > seems too long

Re: dpkg: scripts/mk: add fragment to preen env

2023-01-29 Thread Guillem Jover
Hi! On Thu, 2023-01-05 at 08:48:59 +0300, Konstantin Demin wrote: > I'd like to contribute a Makefile fragment to ease env "preen". Thanks for the patch! > diff --git a/scripts/mk/env-default.mk b/scripts/mk/env-default.mk > new file mode 100644 > index ..54f4af30 > --- /dev/null > +++

Re: Terminology changes for update-alternatives

2023-01-29 Thread Russ Allbery
Justin B Rye writes: > if "primary/secondary" is no good there are variants like "major/minor", > but I think the one I'd have expected to be a front-runner is "main > link" and "subsidiary link", with the latter abbreviating to "Sublinks:" > and "--sub". leader/follower is the other option

Re: Terminology changes for update-alternatives

2023-01-29 Thread Justin B Rye
Julian Andres Klode wrote: >> I'd like to move away from the master/slave terminology used in >> update-alternatives for both the external interfaces (CLI options, >> output fields) obviously preserving backwards compatibility, docs >> and for all the internal code symbols. For the same reasons as

Re: Terminology changes for update-alternatives

2023-01-29 Thread Julian Andres Klode
On Sun, Jan 29, 2023 at 06:00:51AM +0100, Guillem Jover wrote: > Hi! > > I'd like to move away from the master/slave terminology used in > update-alternatives for both the external interfaces (CLI options, > output fields) obviously preserving backwards compatibility, docs > and for all the

Re: Terminology changes for update-alternatives

2023-01-29 Thread David
On Sun, 29 Jan 2023 at 16:01, Guillem Jover wrote: > I'd like to move away from the master/slave terminology used in > update-alternatives for both the external interfaces (CLI options, > output fields) obviously preserving backwards compatibility, docs > and for all the internal code symbols.

Re: Terminology changes for update-alternatives

2023-01-29 Thread Justin B Rye
Guillem Jover wrote: > I'd like to move away from the master/slave terminology used in > update-alternatives for both the external interfaces (CLI options, > output fields) obviously preserving backwards compatibility, docs > and for all the internal code symbols. For the same reasons as mentioned