Sé que esta pregunta se ha hecho antes, pero no acepto la respuesta: "puedes ver claramente las adiciones personalizadas". Cuando agrego ppa (lo que no he hecho en años), presiono una tecla en mi teclado llamada "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 (por el bien del argumento, tal vez tengas 3 o incluso 2, no importa... 1 todavía vence a 2).
¿Alguien puede proponer una ventaja racional? "Se pueden ver claramente adiciones personalizadas" es la excusa de un pobre.
Debo agregar que me encanta el cambio, sin embargo, SÓLO 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 agregue entradas duplicadas.
Ahora, tienen que buscar en un directorio duplicados en lugar de un archivo plano. A menos que asuman que los administradores no cambian las cosas…
Permite a un administrador del sistema desactivar fácilmente (cambiando el nombre) o eliminar (eliminando) un conjunto de repositorios sin tener que editar un archivo monolítico.
El administrador tiene que buscar el directorio para encontrar el archivo apropiado para cambiar el nombre; antes, buscaba UN archivo y comentaba una línea, una frase sed para "casi" cualquier administrador.
Permite al mantenedor de paquetes dar un comando simple para actualizar las ubicaciones de los repositorios sin tener que preocuparse por cambiar inadvertidamente la configuración de repositorios no relacionados.
No entiendo este, "asumo" que el mantenedor del paquete conoce la URL de su repositorio. Nuevamente, tiene que ser sedun directorio en lugar de un solo archivo.
Respuesta1
Tener cada repositorio (o colección de repositorios) en su propio archivo hace que sea más sencillo 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 agregue entradas duplicadas.
- Permite a un administrador del sistema desactivar fácilmente (cambiando el nombre) o eliminar (eliminando) un conjunto de repositorios sin tener que editar un archivo monolítico.
- Permite al mantenedor de paquetes dar un comando simple para actualizar las ubicaciones de los repositorios sin tener que preocuparse por cambiar inadvertidamente la configuración de repositorios no relacionados.
Respuesta2
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 todo se reduce a esto:
Para fuentes.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 se muestra 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 se muestra a continuación, entonces es exactamente la misma complejidad, excepto que se lleva a cabo en muchos archivos, no en uno. Además, a menos que estén verificando TODOS los archivos posibles, pueden agregar, y a menudo lo hacen, un elemento duplicado, lo que luego genera quejas, hasta que elimina uno de ellos.
Para fuentes.lista
# 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 con el nombre exacto que querían.
Ver qué fuentes tienes, por supuesto, no es tan bonito, ya que no hay nada más fácil de leer y mantener que:
cat /etc/sources.list
Básicamente, esto se hizo con el propósito de realizar actualizaciones automáticas y, hasta donde yo sé, para proporcionar comandos únicos y sencillos que podrías dar a los usuarios. 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.
Ya que en el mundo real, si ibas a hacer esto bien, debes soportar verificaciones de todos los archivos, independientemente de cómo se llamen, y luego probar si la acción a realizar es requerida o no.
Sin embargo, si no fuera a hacerlo bien, simplemente ignoraría las comprobaciones para ver si el elemento está en algún lugar de las fuentes y simplemente verificaría el nombre del archivo. Creo que eso es lo que hacen la mayoría de las cosas automatizadas, pero como 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 se ejecutan muchos servidores, estaría tentado a simplemente programar un trabajo nocturno que recorra /etc/apt/sources.list.d/ y verifique primero para asegurarse de que el elemento no esté ya en sources.list, y luego, si lo está. no, agregue ese elemento a fuentes.list, elimine el archivo fuentes.list.d y, si ya está en fuentes.lista, simplemente elimine el archivo fuentes.list.d
Dado que NO hay nada negativo en usar solo fuentes.list más allá de la simplicidad y la facilidad de mantenimiento, agregar algo así podría no ser una mala idea, particularmente dadas las acciones creativas aleatorias de los administradores del sistema.
Como se señaló en el comentario anterior, inxi -r imprimirá cuidadosamente por archivo los repositorios activos, pero, por supuesto, no los editará ni alterará, por lo que eso sería solo la mitad de la solución. Si se trata de muchas distribuciones, es complicado aprender cómo lo hace cada una, eso es seguro, y la aleatoriedad ciertamente es la regla y no la excepción, lamentablemente.
Respuesta3
Si administra sus servidores manualmente, estoy de acuerdo en que hace las cosas más confusas. Sin embargo, beneficia la gestión programática (es decir, la "configuración como código"). Cuando se utiliza software de administración de configuración como Puppet, Ansible, Chef, etc., es más fácil simplemente colocar 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 único recurso de 'archivo', por ejemplo: /etc/apt/sources.list, desde múltiples módulos independientes que han sido escritos por terceros.
Aprecio el amplio uso que hace Ubuntu de los directorios ".d" por esta razón particular, es decir, sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d, etc.
Respuesta4
Esto permite que los paquetes agreguen fuentes adicionales sin recurrir a scripts.
Por ejemplo, cuando instala el paquete Skype de Microsoft, se configura automáticamente una fuente para skype.com para descargar actualizaciones; Eliminar el paquete de Skype del sistema también desactiva nuevamente la fuente de este paquete.
Si quisiera tener el mismo efecto con un archivo plano, entonces los scripts de instalación de Skype necesitarían modificar su lista de fuentes, lo que probablemente muchos administradores de sistemas encontrarían un poco desconcertante.