Re: Can somebody explain the benefits of .d directories

[Michael Milliman]

On 11/27/2017 04:31 PM, Nicolas George wrote:

Hans-Peter (2017-11-27):

I have an honest question which is dead-simple: Why do we have ".d" directories

To allow packages to provide configuration snippets. Packages work at
the file level, they provide sets of files. When a package needs to
provide a configuration snippet, for example when it provides a plugin
for another software, it does so by providing a file. When the package
is upgraded, the normal handling of configuration files can be applied.
Modifying a monolithic configuration file would be much more fragile.
This is the reason that the .d directories were done.  However, I also 
find that for manual configuration, I do almost exactly the same thing.  
For example, if/when I decide to add a third party repository to my 
sources.list files, I usually do it by adding a file to sources.list.d, 
rather than editing the sources.list file. This makes it much easier for 
me to locate specific things in my repository lists.  I simply do an ls 
/etc/sources.list.d and can quickly locate the snippet responsible for a 
particular repository. I have used this strategy for other software 
which has a configuration file that can be pretty large.  I don't have 
to manually search through the file to find the one or two lines I'm 
looking for.

Regards,

Re: Can somebody explain the benefits of .d directories

[Ben Finney]

Hans-Peter  writes:

> I have an honest question which is dead-simple: Why do we have ".d"
> directories, such as "sources.d" or "grub.d", note that with grub, the
> defaults are in another directory tree - this is simply beyond insane.

Your question there seems less than an honest enquiry – asking for the
reason something has come about – and more a rhetorical device.

What specifically is it you think is “beyond insane”? The only thing you
present that seems to address that is:

> […] the downside being having to parse several files vs a single file

which is surely an implementation detail and a design decision, not
warranting any declaration of insanity. Yet you think it so egregious to
be worthy of hyperbolic insult.

> I seriously think this is nonsense, there is no "logical" reason for
> doing this, afaict. Have I missed something ?

Yes; you've missed the opportunity to ask honestly with the expectation
we might convince you of the reason. At this point you are frustrated
and exasperated, and it seems unlikely you will be receptive to a
discussion of benefits and trade-offs.

For example:

> I have asked the question on unix.stackexchange.com and got silly
> answers trying to defend the "it is so much easier to parse x files in
> a directory than a single file" stance (you gotta be kidding!).

If you're going to dismiss explanations as “silly” and “kidding” without
addressing the content, that is totally at odds with your profession of
enquiry:

> I would really appreciate answers on this […]

You have circumscribed the domain of answers you would be receptive to,
such that it seems – based on your current exasperated hyperbole at the
expsting mundane answers – no mundane explanation will satisfy you.

> I have waited many years before reporting this because I lacked
> confidence, but seriously ...I think this is a bug and it needs to be
> fixed. ".d" is braindead, does not add any functionality that cannot
> be replicated with the "Enter" key on a keyboard and, in the worst
> case, a line starting with # followed by some comment.

On those terms, I would advise anyone not to engage with this
discussion.

Please don't disparage the work of those implementing these systems
unless you are willing to accept that those who implement it get to make
the design decisions, and not dismiss those decisions as “silly”, “you
gotta be kidding”, “braindead”, and “beyond insane” — none of which
engage with the actual design or implementation.

-- 
 \ “Don't be afraid of missing opportunities. Behind every failure |
  `\ is an opportunity somebody wishes they had missed.” —Jane |
_o__)  Wagner, via Lily Tomlin |
Ben Finney

Re: Can somebody explain the benefits of .d directories

[Roberto C . Sánchez]

On Mon, Nov 27, 2017 at 05:09:49PM -0500, Hans-Peter wrote:
>I have an honest question which is dead-simple: Why do we have ".d"
>directories, such as "sources.d" or "grub.d", note that with grub, the
>defaults are in another directory tree - this is simply beyond insane.
>(Sorry to quote Linus)
>I am sure this question has been asked before (I have googled for many
>years and have not found an acceptable answer, the downside being having
>to parse several files vs a single file) and I am more than happy to
>accept "change", except that in this case it needlessly increases my
>workload. With ancient UNIX systems, a sed oneliner is enough, with Linux,
>I have to use "grep -r" or use "find" in combination with "sed". I
>seriously think this is nonsense, there is no "logical" reason for doing
>this, afaict. Have I missed something ? I have asked the question on
>unix.stackexchange.com and got silly answers trying to defend the "it is
>so much easier to parse x files in a directory than a single file" stance
>(you gotta be kidding!).

For me, I deploy a file called /etc/sudoers.d/local on every system that
I maintain which ensures that my own local user account, as well as
those of other admins, always have sudo access regardless of their group
memberships.

Deploying that as part of a profile package that gets distributed via an
internal apt repository is far simpler than monkeying with sed.

It also works well for apt sources in /etc/apt/sources.list.d, dpkg
preferences in /etc/dpkg/dpkg.cfg.d, and syslog configurations in
/etc/rsyslog.d to name a few.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Can somebody explain the benefits of .d directories

[Nicolas George]

Hans-Peter (2017-11-27):
> I have an honest question which is dead-simple: Why do we have ".d" 
> directories

To allow packages to provide configuration snippets. Packages work at
the file level, they provide sets of files. When a package needs to
provide a configuration snippet, for example when it provides a plugin
for another software, it does so by providing a file. When the package
is upgraded, the normal handling of configuration files can be applied.
Modifying a monolithic configuration file would be much more fragile.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Can somebody explain the benefits of .d directories

[Hans-Peter]

Hi everyone,


I am a tech writer, as part of my job I also have to maintain a number of 
servers, various UNIX systems. Yes, I am a dev as well 


I have used Debian since 2001 and I do not want to be understood as some UNIX 
nerd or fanatic.


I have an honest question which is dead-simple: Why do we have ".d" 
directories, such as "sources.d" or "grub.d", note that with grub, the defaults 
are in another directory tree - this is simply beyond insane. (Sorry to quote 
Linus)


I am sure this question has been asked before (I have googled for many years 
and have not found an acceptable answer, the downside being having to parse 
several files vs a single file) and I am more than happy to accept "change", 
except that in this case it needlessly increases my workload. With ancient UNIX 
systems, a sed oneliner is enough, with Linux, I have to use "grep -r" or use 
"find" in combination with "sed". I seriously think this is nonsense, there is 
no "logical" reason for doing this, afaict. Have I missed something ? I have 
asked the question on unix.stackexchange.com and got silly answers trying to 
defend the "it is so much easier to parse x files in a directory than a single 
file" stance (you gotta be kidding!).


I would really appreciate answers on this, I never had the nerve to ask this, 
because you all write great software  And yes, I donate ...


I have waited many years before reporting this because I lacked confidence, but 
seriously ...I think this is a bug and it needs to be fixed. ".d" is braindead, 
does not add any functionality that cannot be replicated with the "Enter" key 
on a keyboard and, in the worst case, a line starting with # followed by some 
comment. 


Some admins where I work are happy to rename the files in the ".d" directory to 
their liking ...a silly and futile attempt to stop me from pruning the repos 
the servers use ...h


HP