当构建一个将存储配置文件目录的新软件时/etc，该目录应该被命名software_name.d还是只是software_name？
我似乎找不到关于这个主题的好的风格指南。 Debian 是我心目中的主要发行版，但欢迎提供更通用的风格指南或指南。
“官方”指导优于个人意见。
答案1
目录的典型用途.d是保存多个配置文件（通常共享一个公共文件扩展名，例如*.conf），然后合并或者组成的产生单个逻辑配置。这种机制通常相当于将多个配置文件连接起来形成单个配置文件的机制。
应用程序通常发展为使用.d目录，以便更好地与 Linux 软件包 (deb/rpm) 和包管理器配合使用。目录.d更适合发行版使用包，因为这样包可以简单地将独立文件“拖放到”目录中（这是一个自然的操作，因为包管理/包含文件），而不必编辑共享配置文件添加一个节以插入该特定包。 （在早期的 Linux 发行版中，您会看到软件包正是这样做的，通过安装后和卸载前脚本编辑现有配置文件。）
当应用程序使用多个配置文件时，使用命名的配置目录/etc/software_name更为常见。不同的目的（甚至可能使用不同的文件格式，例如 JSON、ini 文件等）在这种情况下，您可能希望使用一个目录来对同一应用程序的所有配置文件进行分组，但如果您不希望使用其他包（或系统管理员）想要通过将新文件“拖放到”目录中来扩展配置，那么您将不会使用目录.d。
有些系统最终实际上同时使用了两者。例如，yum（Red Hat 软件包管理器）有自己的配置文件，但它也有一个.d自己的存储库目录 ( /etc/yum.repos.d.)，我相信apt也很相似，所以如果您使用的是 Debian，您可以查看该目录。您可以看到该设置是有意义的，因为您可能希望通过将新文件“拖放到”目录中.d（无论是从您推送的包中，还是通过配置管理系统）来管理添加/删除存储库，而不必修改现有的文件（这可能会从操作系统发行版本身获取更新。）
答案2
这里有很多讨论关于这个话题。没有什么是真正明确的。
对于什么是“正确”的“官方”指导，我说最终的来源是文件系统层次结构标准在 Linux 基金会。不幸的是，我通过一些基本搜索没有找到任何明确的信息。您可能会通过更勤奋的搜索而幸运。
如果 FHS 失败，我会向您正在为其编写软件的社区寻求帮助，尝试就他们喜欢的内容达成普遍共识，并确定这是否满足您的要求。我认为您正在寻求实际上不存在的指导，因为在这种情况下“推荐”是一个非常模糊的术语。 “谁推荐的？为谁推荐的？”