On 20/12/2024 12:30, Ansgar 🙀 wrote:
> On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
>> Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
>> > It also avoids the problem of removed-but-not-purged packages.
>>
>> With files copied into /etc, you will still have configuration files
On 2024-12-20 at 11:42 -0800, Russ Allbery wrote:
> Maybe it would be more productive to take the preference disagreement as
> given and then try to figure out how to proceed given that we're never
> going to all agree on the best way of handling configuration files? Is
> there some way that we can
On 2024-12-22 at 08:37 +0100, Marc Haber wrote:
> Maybe our conffile handling should be modified to automatically
> accept comment-only changes to dpkg-conffiles.
>
> Greetings
> Marc
That would require to tag what is considered a comment for each
conffile.
While most config files seem to use a
On Mon, Dec 23, 2024 at 08:23:33AM -0500, Theodore Ts'o wrote:
> On Sat, Dec 21, 2024 at 04:38:46PM -0800, Josh Triplett wrote:
> > On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
> > > > Right now, the model we have is "some packages use the empty /etc model,
> > > > some packages install co
Daniel Gröber writes:
> Debian policy section 10.7.2:
>> Any configuration files created or *used* by your package must reside in
>> /etc, [...]
> (Emphasis mine)
Policy has a specific definition of configuration file, which makes your
point here somewhat ambiguous, but I can understand this mi
Hi Gioele,
On Mon, Dec 23, 2024 at 08:34:57PM +0100, Gioele Barabucci wrote:
> On 23/12/24 16:23, Daniel Gröber wrote:
> > As an example I'm familiar with iproute2 moved it's default config from
> > /etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads*
> > the config from the
On 23/12/24 16:23, Daniel Gröber wrote:
As an example I'm familiar with iproute2 moved it's default config from
/etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads*
the config from there, it's not just example files so in that case upstream
patching or symlink trickery woul
Hi Josh,
On Thu, Dec 19, 2024 at 07:05:56PM -0800, Josh Triplett wrote:
> Suppose that packages ship sample configuration files *that exactly
> match their defaults* (which should in general mean that everything is
> commented out) in some standardized path under /usr/share/doc/$package/
> (e.g. e
On Sat, Dec 21, 2024 at 04:38:46PM -0800, Josh Triplett wrote:
> On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
> >
> >
> > > Right now, the model we have is "some packages use the empty /etc model,
> > > some packages install commented-out defaults, and there's no
> > > consistency". I'd
On Sat, 21 Dec 2024 07:33:46 +0100, Andreas Metzler
wrote:
>On 2024-12-19 Andrey Rakhmatullin wrote:
>> On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start
On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
>
>
> > Right now, the model we have is "some packages use the empty /etc model,
> > some packages install commented-out defaults, and there's no
> > consistency". I'd love to move to the model of "all packages use
> > whichever model the sysa
On 2024-12-19 Andrey Rakhmatullin wrote:
> On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
>>> And it is actively harmful as if one edits the example configuration to
>>> have a useful configuration as dpkg will start annoying admins with
>>> "the example configuration has changed
Russ Allbery wrote:
> And this is the root of the problem: you want one thing for understandable
> reasons, and other people, like myself, would prefer the opposite behavior
> of having /etc empty by default for different understandable reasons. We
> both understand the other's point of view and si
On Fri, 20 Dec 2024 11:50:57 +0100, Samuel Thibault
wrote:
>Josh Triplett, le ven. 20 déc. 2024 02:05:30 -0800, a ecrit:
>> I'm talking about the "empty /etc" model here, which is why I'm trying
>> to find a solution so that people who *want* the file-full-of-comments
>> have it, without installin
Samuel Thibault writes:
> It seems way more often to me that I want to easily inspect/modify/amend
> the configuration in /etc (without having to look whatever other place
> to find out about the default configuration) than checking what changes
> I have made to /etc which I may not want any more
> Right now, the model we have is "some packages use the empty /etc model,
> some packages install commented-out defaults, and there's no
> consistency". I'd love to move to the model of "all packages use
> whichever model the sysadmin prefers".
As a long-time sysadmin - and following on my pre
>
>> Suppose that packages ship sample configuration files *that exactly
>> match their defaults* (which should in general mean that everything is
>> commented out) in some standardized path under /usr/share/doc/$package/
>> (e.g. examples/etc), that makes it easy to see what path the example
>
Ansgar 🙀, le ven. 20 déc. 2024 13:07:36 +0100, a ecrit:
> On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
> > Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> > > On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > > > What I completely fail to understand is why people
Henrik Ahlgren, le ven. 20 déc. 2024 13:47:24 +0200, a ecrit:
> On Fri, 2024-12-20 at 12:01 +0100, Ansgar 🙀 wrote:
> > With empty-/etc, you would (ideally) only have explicit local
> > configuration in /etc which makes it much, much easier to see what the
> > local admin changed to diagnose problem
On Fri, 20 Dec 2024 02:05:30 -0800
Josh Triplett wrote:
>
> I'm talking about the "empty /etc" model here, which is why I'm trying
> to find a solution so that people who *want* the file-full-of-comments
> have it, without installing it for people who *don't* want it.
This sounds to be a reasona
Hi,
On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
> Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> > On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > > What I completely fail to understand is why people would want to not
> > > see any file in /etc. What harm doe
Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > What I completely fail to understand is why people would want to not
> > see any file in /etc. What harm does it *actually* cause?
>
> It makes it hard to see what was actually c
On Fri, 2024-12-20 at 12:01 +0100, Ansgar 🙀 wrote:
> With empty-/etc, you would (ideally) only have explicit local
> configuration in /etc which makes it much, much easier to see what the
> local admin changed to diagnose problems, prepare upgrades and so on.
> This is practically impossible now.
On Thu, Dec 19, 2024 at 08:36:25AM -0600, rhys wrote:
>
>
> >
> >> What group of idiots came up with a system where instead of having all of
> >> the configs in maximum of two places (/etc | ~/.config) have now spread
> >> them out across five completely separate directory trees?
> >
> > The
Hi,
On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> What I completely fail to understand is why people would want to not
> see any file in /etc. What harm does it *actually* cause?
It makes it hard to see what was actually configured: there is random
configuration bits, possibly from
Josh Triplett, le ven. 20 déc. 2024 02:05:30 -0800, a ecrit:
> On Fri, Dec 20, 2024 at 09:55:17AM +0100, Samuel Thibault wrote:
> > Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> > > Samuel Thibault wrote:
> > > > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > > > And
On Fri, Dec 20, 2024 at 09:55:17AM +0100, Samuel Thibault wrote:
> Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> > Samuel Thibault wrote:
> > > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > > And it is actively harmful as if one edits the example configuration to
>
Richard Lewis, le ven. 20 déc. 2024 09:42:11 +, a ecrit:
> but perhaps what is missing is a way to see what changed on upgrade
> (you'd want to save the clean version from the _previous_ version of a
> package to be able to do that after the upgrade)?
You mean ucf?
Samuel
Henrik Ahlgren, le ven. 20 déc. 2024 11:32:37 +0200, a ecrit:
> On Fri, 2024-12-20 at 09:55 +0100, Samuel Thibault wrote:
> > But isn't it what we already have? If I don't modify the example in /etc
> > and only add files to .d/, I'm getting upgrades without questions.
> > And if I modify the examp
Josh Triplett writes:
> Suppose that packages ship sample configuration files *that exactly
> match their defaults* (which should in general mean that everything is
> commented out) in some standardized path under /usr/share/doc/$package/
> (e.g. examples/etc), that makes it easy to see what pat
On Fri, 2024-12-20 at 09:55 +0100, Samuel Thibault wrote:
> But isn't it what we already have? If I don't modify the example in /etc
> and only add files to .d/, I'm getting upgrades without questions.
> And if I modify the example in /etc, I'm getting the question. That way
> I can decide per-pack
Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> Samuel Thibault wrote:
> > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > And it is actively harmful as if one edits the example configuration to
> > > have a useful configuration as dpkg will start annoying admins with
>
Samuel Thibault wrote:
> Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > And it is actively harmful as if one edits the example configuration to
> > have a useful configuration as dpkg will start annoying admins with
> > "the example configuration has changed; what do you want to do"
>
On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
> > And it is actively harmful as if one edits the example configuration to
> > have a useful configuration as dpkg will start annoying admins with
> > "the example configuration has changed; what do you want to do"
> > messages.
>
>
Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> On Thu, 2024-12-19 at 11:16 +0100, Samuel Thibault wrote:
> > Also, /etc would thus be full of empty /etc/$proj directories? I don't
> > see the point of not just putting the example files there? Why making it
> > more difficult for the admi
Hi,
On Thu, 2024-12-19 at 11:16 +0100, Samuel Thibault wrote:
> Also, /etc would thus be full of empty /etc/$proj directories? I don't
> see the point of not just putting the example files there? Why making it
> more difficult for the admin to configure their server?
Examples belong to /usr/share
Hi,
On Thu, 2024-12-19 at 12:34 +0100, Frank Guthausen wrote:
> On Thu, 19 Dec 2024 11:00:03 +0100
> Ansgar 🙀 wrote:
> > On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
> > >
> > > Debian GNU/Systemd is only an unofficial
> > > subdistribution of Debian GNU/Linux. YMMV
> >
> > Pleas
>
>> What group of idiots came up with a system where instead of having all of
>> the configs in maximum of two places (/etc | ~/.config) have now spread them
>> out across five completely separate directory trees?
>
> The group is called "The Linux Userspace API (UAPI) Group", and according
On Thu, 2024-12-19 at 07:08 -0600, rhys wrote:
>
> What group of idiots came up with a system where instead of having all of the
> configs in maximum of two places (/etc | ~/.config) have now spread them out
> across five completely separate directory trees?
The group is called "The Linux User
>>>
>>> $ cp /usr/lib/$proj/foo.conf /etc/$proj/
>>
>> Which is not trivial, really.
Well, it IS, but in the same way that "rm -rf /" is trivial. It's easy to do,
but some non-trivial thought should occur before doing it.
> Put another way: would it really be /usr/lib/$proj, or
>
> this is what can be called "old style" overrides.
Things get to be "old" because they actually work well.
> The modern way of doing it is the "stateless" style, most commonly associated
> with systemd but used by plenty of other projects, plus "drop-in" .d
> directories.
>
> The basic
On Thu, 19 Dec 2024 12:34:57 +0100, Frank Guthausen
wrote:
>If my suggestions do not apply to situations where systemd is used,
>I'd suggest systemd advocates to stay quiet because the topic does
>not concern them
That nicely helps me to put your suggestion in the correct
compartment, which is th
On Thu, 19 Dec 2024 11:00:03 +0100
Ansgar 🙀 wrote:
> On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
> >
> > Debian GNU/Systemd is only an unofficial
> > subdistribution of Debian GNU/Linux. YMMV
>
> Please keep such messages to appropriate mailing lists such as the
> Devuan list
As
Hi,
On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
> On Thu, 19 Dec 2024 09:01:09 +0100
> Marco d'Itri wrote:
> >
> > No: the expected default for systemd-managed services is to use
> > /etc/$SERVICE/ .
>
> Debian GNU/Systemd is only an unofficial
> subdistribution of Debian GNU/Lin
Samuel Thibault, le jeu. 19 déc. 2024 10:26:12 +0100, a ecrit:
> Gioele Barabucci, le jeu. 19 déc. 2024 10:22:02 +0100, a ecrit:
> > On 19/12/24 10:19, Samuel Thibault wrote:
> > > Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
> > > > * Admin can override the standard configuratio
On Thu, 19 Dec 2024 10:09:41 +0100, Frank Guthausen
wrote:
>Debian GNU/Systemd is only an unofficial
>subdistribution of Debian GNU/Linux.
Bullshit.
--
Marc Haber | " Questions are the | Mailadresse i
On Thu, 19 Dec 2024 18:03:06 +0900
Simon Richter wrote:
> On 12/19/24 16:17, Frank Guthausen wrote:
>
> > A lot of packages do default configuration in /etc/project.conf and
> > admin related stuff in /etc/project.d/whatsoever.conf to separate
> > the distribution part from local overrides.
>
Gioele Barabucci, le jeu. 19 déc. 2024 10:22:02 +0100, a ecrit:
> On 19/12/24 10:19, Samuel Thibault wrote:
> > Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
> > > * Admin can override the standard configuration via /etc/$proj/foo.conf
> > [...]
> > > Upstream projects are moving
On 19/12/24 10:19, Samuel Thibault wrote:
Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
* Admin can override the standard configuration via /etc/$proj/foo.conf
[...]
Upstream projects are moving to this style. I hope that one day Debian
packages will stop shipping files under
Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
> * Admin can override the standard configuration via /etc/$proj/foo.conf
[...]
> Upstream projects are moving to this style. I hope that one day Debian
> packages will stop shipping files under /etc.
Having pre-filled configuration f
On 19/12/24 08:17, Frank Guthausen wrote:
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.
Hi,
this is what can be called "old style" overrides.
The modern way of d
On Thu, 19 Dec 2024 09:01:09 +0100
Marco d'Itri wrote:
>
> No: the expected default for systemd-managed services is to use
> /etc/$SERVICE/ .
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV
--
kind regards
Frank
pgp3MLhxRVRIo.pgp
Description: OpenPGP digita
Hi,
On 12/19/24 16:17, Frank Guthausen wrote:
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.
It depends on the package.
Some packages have a "registry-style" con
On Dec 19, Frank Guthausen wrote:
> Is it reasonable to use this idea as "best practice" and implement it
> into Debian style administration recommendations? It works very well
No: the expected default for systemd-managed services is to use
/etc/$SERVICE/ .
--
ciao,
Marco
signature.asc
Descr
54 matches
Mail list logo
