¿Cuál es el beneficio de /etc/apt/sources.list.d sobre /etc/apt/sources.list

Sé que esta pregunta se ha hecho antes, pero no acepto la respuesta, "puede ver claramente adiciones personalizadas". Cuando agrego ppa's (que no he hecho en años), presiono una tecla en mi teclado con la etiqueta "Enter" que me permite agregar una línea vacía antes de la nueva entrada (incluso agregaría un comentario explicativo, pero soy un escritor de tecnología, entonces ...). Me gusta mi sources.conflimpio y ordenado.

/etc/apt/sources.d

Significa que tengo media docena de archivos para analizar en lugar de solo uno.

AFAIK, no hay "absolutamente" ninguna ventaja en tener un archivo de configuración frente a 6 (en aras de la discusión, tal vez tenga 3 o incluso 2, no importa ... 1 todavía supera a 2).

¿Alguien puede aportar una ventaja racional? "Puede ver claramente adiciones personalizadas" es la excusa de un hombre pobre.

Sin embargo, debo agregar que me encanta el cambio SOLO cuando el cambio introduce beneficios.

Editar después de la primera respuesta:

Permite que las nuevas instalaciones que necesitan sus propios repositorios no tengan que buscar un archivo plano para asegurarse de que no está agregando entradas duplicadas.

Ahora, tienen que buscar un directorio de duplicados en lugar de un archivo plano. A menos que asuman que los administradores no cambian las cosas ...

Permite al administrador del sistema deshabilitar fácilmente (renombrando) o eliminar (borrando) un conjunto de repositorios sin tener que editar un archivo monolítico.

El administrador tiene que buscar el directorio grep para encontrar el archivo apropiado para cambiarle el nombre, antes, buscaría UN archivo y comentaría una línea, una línea de sed para "casi" cualquier administrador.

Permite que un mantenedor de paquetes dé un comando simple para actualizar las ubicaciones del repositorio sin tener que preocuparse por cambiar inadvertidamente la configuración de repositorios no relacionados.

No entiendo este, supongo que el mantenedor del paquete conoce la URL de su repositorio. De nuevo, tiene sedun directorio en lugar de un solo archivo.

A nivel técnico, como alguien que ha tenido que manejar estos cambios en algunas herramientas de información del sistema grandes y populares, básicamente se reduce a esto:

Para sources.list.d /

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

Tenga en cuenta que a menos que también estén haciendo la misma verificación que a continuación, si hubiera comentado una línea de repositorio, estas pruebas serían incorrectas. Si están haciendo la misma verificación que a continuación, es la misma complejidad exacta, excepto que se realiza en muchos archivos, no en uno. Además, a menos que estén revisando TODOS los archivos posibles, pueden, y a menudo lo hacen, agregar un elemento duplicado, lo que hace que se quejen, hasta que elimine uno de ellos.

Para fuentes.list

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

Los desarrolladores de Google Chrome no verificaron la presencia de fuentes de Google Chrome, confiando en el nombre de archivo exacto que su paquete de Chrome crearía para estar presente. En todos los demás casos, crearían un nuevo archivo en sources.list.d llamado exactamente de la manera que querían.

Para ver qué fuentes tiene, por supuesto, no es tan bonito, ya que no puede ser más fácil de leer y mantener que:

cat /etc/sources.list

Así que esto se hizo básicamente con el propósito de actualizaciones automáticas, y para proporcionar comandos simples y sencillos que podría dar a los usuarios, por lo que puedo decir. Para los usuarios, significa que tienen que leer muchos archivos en lugar de 1 archivo para ver si tienen un repositorio agregado, y para apt, significa que también tienen que leer muchos archivos en lugar de uno.

Dado que en el mundo real, si iba a hacer esto bien, debe respaldar las comprobaciones de todos los archivos, independientemente de su nombre, y luego probar si la acción a realizar es obligatoria o no.

Sin embargo, si no lo hiciera bien, simplemente ignoraría las verificaciones para ver si el elemento está en algún lugar de las fuentes, y simplemente verificará el nombre del archivo. Creo que eso es lo que hace la mayoría de las cosas automatizadas, pero dado que al final, simplemente tuve que verificar todo para poder enumerarlo y actuar en función de si uno de esos archivos coincidía, el único resultado real fue hacerlo mucho más complicado.

Ediciones masivas

Dado que ejecuta muchos servidores, me vería tentado a simplemente escribir un trabajo nocturno que recorre /etc/apt/sources.list.d/ y comprueba primero para asegurarse de que el elemento ya no esté en sources.list, luego si está no, agregue ese elemento a sources.list, elimine el archivo sources.list.d y, si ya está en sources.list, simplemente elimine el archivo sources.list.d

Dado que NO hay nada negativo en usar solo sources.list más allá de la simplicidad y la facilidad de mantenimiento, agregar algo así podría no ser una mala idea, en particular dadas las acciones aleatorias creativas de los administradores del sistema.

Como se señaló en el comentario anterior, inxi -r imprimirá perfectamente por archivo los repositorios activos, pero por supuesto no los editará o alterará, por lo que eso sería solo la mitad de la solución. Si se trata de muchas distribuciones, es un dolor aprender cómo cada uno lo hace, eso es seguro, y la aleatoriedad ciertamente es la regla más que la excepción, lamentablemente.

Tener cada repositorio (o colección de repositorios) en su propio archivo hace que sea más fácil de administrar, tanto a mano como mediante programación:

• Permite que las nuevas instalaciones que necesitan sus propios repositorios no tengan que buscar un archivo plano para asegurarse de que no está agregando entradas duplicadas.
• Permite al administrador del sistema deshabilitar fácilmente (renombrando) o eliminar (borrando) un conjunto de repositorios sin tener que editar un archivo monolítico.
• Permite que un mantenedor de paquetes dé un comando simple para actualizar las ubicaciones del repositorio sin tener que preocuparse por cambiar inadvertidamente la configuración de repositorios no relacionados.

Si está administrando manualmente sus servidores, estoy de acuerdo en que hace las cosas más confusas. Sin embargo, beneficia la gestión programática (es decir, "configuración como código"). Cuando se utiliza un software de gestión de configuración como Puppet, Ansible, Chef, etc., es más fácil simplemente soltar o eliminar un archivo en un directorio y ejecutarlo apt update, en lugar de analizar un archivo para agregar o eliminar ciertas líneas.

Especialmente porque eso evita tener que administrar el contenido de un solo recurso 'archivo', por ejemplo /etc/apt/sources.list, desde múltiples módulos independientes que han sido escritos por terceros.

Aprecio el uso generalizado de Ubuntu de los directorios ".d" por este motivo en particular, es decir, sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d, etc.

Como señaló Nemo en un comentario, una de las principales ventajas de un directorio es que permite la noción de "propiedad".

Las distribuciones e instaladores modernos de Linux se basan en la idea de paquetes : piezas de software independientes que, en la medida de lo posible, se pueden agregar y eliminar atómicamente. Cada vez que instala un paquete con dpkg(y por lo tanto apt), realiza un seguimiento de qué archivos en el sistema fueron creados por ese instalador. Desinstalar el paquete puede consistir en gran medida en eliminar esos archivos.

La respuesta actualmente aceptada lo toma como algo malo que un instalador de Google Chrome supuso que solo debería crear o eliminar una entrada en la ubicación que esperaba, pero automatizar cualquier otra cosa conduce a todo tipo de casos extremos horribles; por ejemplo:

• Si la línea existe sources.listdurante la instalación, pero está comentada, ¿debería el instalador descomentarla o agregar un duplicado?
• Si el desinstalador elimina la línea, pero el usuario ha agregado o editado comentarios al lado, el archivo se quedará con comentarios rotos.
• Si el usuario agregó la línea manualmente, el instalador podría saber que no debe agregarla; pero, ¿cómo sabría el desinstalador que no lo eliminará?

No se requieren archivos separados para la propiedad; por ejemplo, el instalador podría incluir un bloque de comentarios que indiquen que "posee" un conjunto particular de líneas. En ese caso, siempre buscaría en el archivo ese bloque exacto, no alguna otra mención del mismo repositorio.

En igualdad de condiciones, automatizar las ediciones en un solo archivo de configuración siempre será más complicado que automatizar la creación y eliminación de un archivo separado. Como mínimo, eliminar líneas requiere el uso de alguna herramienta de coincidencia de patrones como sed. En un archivo más complejo, agregar y eliminar líneas puede requerir una herramienta de secuencias de comandos con conocimiento del formato de archivo, para agregar a una sección adecuada o eliminar sin dañar el formato circundante.

Dado que un instalador necesitaría evitar meterse con la configuración editada manualmente de todos modos, tiene sentido colocar la configuración automatizada, propiedad de la herramienta, en un formato que sea fácil de administrar para las herramientas automatizadas.

Esto permite que los paquetes agreguen fuentes adicionales sin recurrir a scripts.

Por ejemplo, cuando instala el paquete Skype de Microsoft, una fuente para skype.com se configura automáticamente para descargar actualizaciones; eliminar el paquete de Skype del sistema también deshabilita esta fuente de paquete nuevamente.

Si desea tener el mismo efecto con un archivo plano, entonces los scripts de instalación para Skype necesitarían modificar su sources.list, lo que probablemente muchos administradores del sistema encontrarían un poco desconcertante.

No estoy convencido de que haya una buena razón, aparte de que parece estar de moda. Para mí, rompe la regla de que un directorio debe ser una hoja o un nodo, es decir, que debe contener solo archivos o directorios, no una mezcla de ambos.

Supongo que hace que los archivos sean más pequeños, más fáciles de leer; en el caso, por ejemplo, de las reglas de sudo, que pueden ser bastante largas, hace que sea más fácil tener un conjunto estandarizado de reglas para un tipo de usuario (por ejemplo, un desarrollador ) y agréguelos al directorio de configuración si se debe permitir a los desarrolladores sudo en esta máquina; por lo tanto, necesita mantener menos archivos, solo un archivo para desarrolladores, administradores, sysops, etc., en lugar de cada combinación posible de los mismos.

Ahí me he contradicho.