Pautas de empaquetamiento de Hyperbola

Las Pautas de empaquetamiento de Hyperbola son el compromiso que nosotros, el Proyecto Hyperbola, hacemos a la Comunidad de Software Libre en general y a nuestros usuarios en particular. Es por esto que nuestras pautas de empaque siempre seguirán la filosofía de libertad, privacidad, estabilidad y seguridad.

  1. Libertad: Todos los paquetes siguen las Pautas para Distribuciones de Sistema Libres. No incluyen ni recomiendan software o documentación no libre y no proporcionan ningún tipo de soporte para la instalación o ejecución de software no libre. Esto incluye:
  2. Privacidad: El objetivo de Hyperbola es apoyar la privacidad de su comunidad. Esto incluye:
    • a) Software creado y parcheado para estar a salvo de la vigilancia de datos global revelada en la publicación de los documentos de la NSA de Snowden.
    • b) Paquetes adicionales reforzados que eliminan los protocolos de nivel inferior que pueden causar fugas de privacidad, metadatos/huellas digitales, y vulnerabilidades.
  3. FHS: Todos los paquetes siguen el Estándar de jerarquía del sistema de archivos (FHS), que define los directorios principales y su contenido en GNU/Linux y otros sistemas operativos informáticos similares a Unix como GNU/Hurd. Por lo tanto, todos los paquetes deben repararse utilizando el estándar requerido sin excepciones.
  4. Proyectos de Software Libre: Si hay software que contiene una versión estable, entonces la versión anterior debe estar en la lista negra. Hay ejemplos como:
    • a) El soporte a largo plazo (LTS) del kernel de Linux-libre en lugar del más actualizado.
    • b) La versión de soporte extendido (ESR) de la versión libre de Iceweasel en lugar de la última versión.
    • c) La versión estable de Nginx en lugar de la línea principal.
    • d) La versión fija de LibreOffice en lugar de la nueva.
    • e) La versión estable de GnuPG en lugar de la moderna.
  5. Anti-abandonware: Hyperbola considera que los proyectos huérfanos sin correcciones de errores y parches activan la actividad como un problema de seguridad y deben ser incluidos en la lista negra. Se consideran excepciones:
    • a) Si se necesita un paquete para una funcionalidad y no hay un reemplazo actual para él.
    • b) Si un paquete es una dependencia importante para proyectos activos y no hay un reemplazo actual para él.
    • c) Si un paquete es un controlador, firmware o emulación de hardware y no hay un reemplazo actual para él.
  6. Snapshot versions: Dado que Hyperbola es una distribución de soporte a largo plazo (LTS); todos los paquetes se basan en las instantáneas de Arch a partir de la fecha mencionada en las listas de correo de Hyperbola o en la página principal, y están diseñados para ser soportados por un período más largo de lo normal hasta la próxima versión estable. Se consideran excepciones:
    • a) Si una versión del paquete en la instantánea es 1.1.0, y hay una solución de error en 1.1.1, podría actualizarse porque es una revisión, no una actualización fuerte o un cambio drástico de versión.
    • b) Si la versión de un paquete en la instantánea es 1.1.0.a, y hay una solución de error en 1.1.0.b, podría actualizarse porque es una revisión, no una actualización segura o un cambio drástico de versión.
    • c) Si una versión del paquete en la instantánea es 1.1.0-beta, y hay una versión final en 1.1.0, podría actualizarse.
    • d) Si una versión del paquete en la instantánea es 1.1.0-beta sin planes para una versión final, y hay un 2.0.0-rc, podría actualizarse como una excepción.
    • e) Si la versión de un paquete en la instantánea es 1.1.0 y depende de un proyecto de abandware (por ejemplo, OpenRC 0.25.x depende de SysVinit), y hay un 1.2.0 con un reemplazo, podría actualizarse como una versión de corrección de errores. (Por ejemplo, SysVinit es reemplazado por openrc-init en OpenRC 0.28.x).
    • f) Si una versión de paquete en la instantánea es un proyecto de soporte a largo plazo (LTS), todas las versiones secundarias de una serie de lanzamientos se aceptan como excepción, como la serie ESR 52 en la versión libre de Iceweasel (por ejemplo, 52.x.x).
    • g) Si una versión de un paquete necesita tomar partes de seguridad de una versión más nueva, pero no es eficiente realizar una copia inversa, una versión más reciente podría considerarse una excepción (consulte la enmienda de Backporting para obtener más detalles)
  7. Lanzamiento del paquete: Todos los paquetes contienen un número de versión específico en pkgrel para que los mantenedores de paquetes realicen actualizaciones en los indicadores de configuración del paquete dentro de PKGBUILD. Normalmente, se establece en 1 para cada nueva versión de software ascendente estable y se incrementa para las actualizaciones de PKGBUILD intermedias, sin embargo, si un paquete proviene de Arch o AUR con modificaciones hechas para Hyperbola, entonces debe establecerse en “$archreleasenumber.hyperbola$hyperbolareleasenumber” (por ejemplo: pkgrel=1.hyperbola1). Se consideran excepciones:
    • a) Si un paquete no fue modificado de los paquetes oficiales de Arch o AUR.
    • b) Si un paquete se creó a partir de un proyecto de reemplazo libre (por ejemplo, kernel de Linux-libre) u otro proyecto libre no incluido en Arch o AUR.
  8. Backporting: Hyperbola usa el término backporting para describir un paquete creado a partir de una versión más nueva, ajustada y adaptada para su uso en la versión estable actual. Requiere que se vuelva a empaquetar con la versión del paquete correspondiente “backports$backportsreleasenumber” para los paquetes oficiales Arch, AUR o Hyperbola (por ejemplo, pkgrel=1.backports1) y los paquetes Arch o AUR modificados por Hyperbola (por ejemplo pkgrel=1.hyperbola1.backports1) hasta la próxima versión estable. Backporting se acepta en Hyperbola como excepción, pero bajo las siguientes condiciones:
    • a) Si el paquete actual utilizado en la versión estable actual necesita muchas modificaciones repartidas en varios archivos del código para resolver algún problema específico (por ejemplo, un problema de seguridad) y es ineficiente de arreglarse.
    • b) Todos los paquetes de la versión más reciente y su biblioteca de la versión más nueva requerida, y los paquetes de dependencia también se deben volver a empaquetar con la versión apropiada del paquete, ya que se reconstruirá en un entorno estable para que se ejecute sin nuevas bibliotecas. Este sufijo se aplica hasta la próxima versión estable.
    • c) Todos los paquetes de la versión más reciente deben seguir las reglas de las Snapshot versions desde las Pautas de Empaquetado de Hyperbola usando su fecha de lanzamiento como una Snapshot version, lo que significa que la Hyperbola no aceptará cambios drásticos recurrentes de la versión siempre que sea posible su corrección.
  9. Licencias de los Paquetes: Todos los paquetes contienen un campo de licencia que especifica la fuente de la licencia que se aplica al paquete utilizando las licencias de uso común en /usr/share/licenses/common. Significa que, si una fuente está bajo una licencia que está disponible en /usr/share/licenses/common (por ejemplo, GPL-2), simplemente se debe hacer referencia en el campo de licencia del paquete (por ejemplo, license=('GPL-2')). Si no es el caso, debe incluirse en el paquete y establecer la licencia = ('custom:LicenseName'). El archivo de licencia se debe colocar en /usr/share/licenses/$pkgname al compilar el paquete. Si se aplican múltiples licencias, las condiciones son:
    • a) Si una fuente actualizada proporciona la preferencia de elegir una licencia, agregue solo esa licencia en el campo de licencia del paquete. La licencia elegida debe ser compatible con las dependencias de la biblioteca vinculada utilizadas por el paquete. (por ejemplo, si la licencia elegida para ffmpeg es la versión 3 de LGPL, entonces se debe agregar el parámetro de configuración `–enable-version3` en PKGBUILD de ffmpeg para activar esta opción de licencia y usar las bibliotecas compatibles con LGPL-3).
    • b) Si una fuente actualizada contiene archivos con muchas licencias diferentes, agregue solo los principales en el campo de licencia del paquete.
    • c) Todos los archivos de licencia primaria y compatible elegidos de la fuente actualizada deben colocarse en /usr/share/licenses/$pkgname.
  10. Parches de Debian: Todos los paquetes contienen parches de seguridad/estabilidad de Debian para seguir el Contrato Social y el programa quilt para automatizar la aplicación de parches. El mdadm's PKGBUILD se usa como ejemplo para todos los paquetes. Se consideran excepciones:
    • a) Si Debian no mantiene el paquete requerido. En este caso, deberíamos usar los parches Devuan o Gentoo.
    • b) Si no hay parches disponibles para el paquete requerido.
    • c) Para kernels de Linux-libre.
  11. HTTPS y tarballs: Todos los paquetes deben construirse desde la fuente a través de su archivo tar oficial, no desde un sistema de control de versiones (VCS). Por lo tanto, todos los paquetes deben repararse utilizando el tarball requerido de su sitio HTTPS. Se consideran excepciones:
    • a) Si no hay un sitio HTTPS. En este caso, HTTP es la opción alternativa.
    • b) Si no hay un sitio HTTP. En este caso, FTP es la opción alternativa.
    • c) Si no hay un tarball oficial. En este caso, tarballs de los repositorios oficiales de Debian es la opción alternativa.
    • d) Si hay un tarball oficial, sin embargo los tarballs de los repositorios oficiales de Debian contienen correcciones de errores. En este caso, los archivos comprimidos oficiales de Debian deben usarse por defecto. (por ejemplo. Mutt+NeoMutt bugfixes)
    • e) Si hay un archivo tar oficial, sin embargo, se requiere que los submódulos de descarga de Git se creen desde la fuente. En este caso, tarballs de los repositorios oficiales de Debian es la opción alternativa.
    • f) Si no hay un tarball oficial. En este caso, se debe utilizar en un tag o rama específica de un sistema de control de versiones (VCS) y se debe volver a empaquetar con el sufijo apropiado (por ejemplo, -bzr para Bazaar, -git para Git, -hg para Mercurial y -svn para Subversion) hasta que esté disponible una versión final.
    • g) Si no hay soporte para GNU/Linux en tarballs, tags o ramas. En este caso, una rama maestra de un sistema de control de versiones (VCS) se podría usar temporalmente y se podría volver a empaquetar con el sufijo apropiado (por ejemplo, -bzr para Bazaar, -git para Git, -hg para Mercurial y -svn para Subversion) hasta que esté disponible una versión final con soporte de GNU/Linux.
  12. SHA-512: Todos los paquetes deben usar solamente SHA-512 funciones hash criptográficas. No se deben usar otras funciones hash criptográficas como MD5 y SHA-1 porque están gravemente comprometidas. Se consideran excepciones:
    • a) Si el paquete utiliza un sistema de control de versiones (VCS) porque no contiene soporte GNU/Linux y/o archivos comprimidos.
  13. GPG: Todos los paquetes deben utilizar verificación de firma. Se consideran excepciones:
    • a) Si los tarballs no contienen firmas.
  14. Anti-ofuscación: la ofuscación es el acto deliberado de crear un código ofuscado, es decir, un código fuente o de máquina que es difícil de entender para los humanos. Todo el código confuso será rechazado sin excepciones.