Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"default-jre" debería ser una dependencia del .deb #259

Open
calaixera opened this issue May 8, 2022 · 3 comments
Open

"default-jre" debería ser una dependencia del .deb #259

calaixera opened this issue May 8, 2022 · 3 comments

Comments

@calaixera
Copy link

calaixera commented May 8, 2022

Autofirma es una aplicación en Java que no va a funcionar sin éste instalado, pero además, instalar el deb de Autofirma disponible en https://firmaelectronica.gob.es/Home/Descargas.html en una máquina sin Java (Debian Sid en este caso) resulta en el siguiente error que deja una instalación rota:

$ sudo dpkg -i AutoFirma_1_7_1.deb 
(S'està llegint la base de dades… hi ha 195184 fitxers i directoris instal·lats actualment.)
S'està preparant per a desempaquetar AutoFirma_1_7_1.deb…
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Se ha borrado el certificado CA en el almacenamiento del sistema
S'està desempaquetant autofirma (1.7.1) sobre (1.7.1)…
Desinstalación completada con exito
S'està configurant autofirma (1.7.1)…
/var/lib/dpkg/info/autofirma.postinst: 3: java: not found
Generacion de certificados
Instalacion del certificado CA en el almacenamiento de Firefox y Chrome
Can't open /usr/lib/AutoFirma/AutoFirma_ROOT.cer for reading, No such file or directory
140525233296768:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('/usr/lib/AutoFirma/AutoFirma_ROOT.cer','rb')
140525233296768:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
unable to load certificate
mv: ha fallat stat() sobre '/usr/lib/AutoFirma/AutoFirma_ROOT.pem': El fitxer o directori no existeix
cp: ha fallat stat() sobre '/usr/lib/AutoFirma/AutoFirma_ROOT.crt': El fitxer o directori no existeix
cp: ha fallat stat() sobre '/usr/lib/AutoFirma/AutoFirma_ROOT.crt': El fitxer o directori no existeix
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Instalacion del certificado CA en el almacenamiento del sistema
rm: no s’ha pogut eliminar '/usr/lib/AutoFirma/script.sh': El fitxer o directori no existeix
rm: no s’ha pogut eliminar '/usr/lib/AutoFirma/AutoFirma_ROOT.crt': El fitxer o directori no existeix
S'estan processant els activadors per a mailcap (3.70+nmu1)…
$ AutoFirma 
/usr/bin/AutoFirma: línia 2: java: no s'ha trobat l'ordre

Aunque no he podido probarlo, seguramente la experiencia de usuario a la hora de instalarlo será mucho peor a la hora de instalarlo en Ubuntu o similares con gdebi o software-center o similar...

La buena noticia es que esto tiene fácil solución y es añadir "default-jre" como dependencia del deb. "default-jre" es un paquete virtual que en Debian y derivados instala automáticamente la versión de Java recomendada por la distribución, de forma portable y predecible entre versiones. A dia de hoy, en todas los lanzamientos soportados de Debian y Ubuntu, este instala automáticamente openjdk-11-jre (menos en Ubuntu Bionic, que aún tiene soporte e instala openjdk-8-jre). De actualizarse esta dependencia en un futuro, esta apuntará a la futura LTS, que es Java 17.

A día de hoy, la única dependencia del deb es "libnss3-tools"

@chartre
Copy link

chartre commented Jun 6, 2022

Confirmo el problema de la dependencia de java en Ubuntu 22.04. No ha dado error desde el gestor de paquetes, pero no inicia porque, obviamente, no hay una instalación de Java...

@Gamuci
Copy link
Contributor

Gamuci commented Jun 14, 2022

El motivo por el que originalmente se indicó esa dependencia como recomendación en lugar de como obligatoria fue que había usuarios que preferían usar concretamente la JVM de Oracle, OpenJdk o algún otro fabricante, o incluso una versión concreta de Java que ya tuviesen instalada. Al indicar "default-jre" simplemente podían estar instalando algo distinto a lo que querían. ¿Alguna recomendación?

@chartre
Copy link

chartre commented Jun 15, 2022

Desde un punto de vista totalmente inocente, al menos se podría enviar una notificación para alertar de la ausencia de Java. Algo como notify-send (desconozco si los .deb tienen algún mecanismo para notificaciones o pop-ups) Algo del estilo a: AutoFirma ha detectado ausencia de Java, por favor revise los requisitos en la documentación.
Al menos así se pondrá sobre la pista del problema.

LucasFA added a commit to LucasFA/clienteafirma that referenced this issue Nov 4, 2023
Exige la existencia de alguna librería de Java >= 11 sin exigir
ninguna versión o proveedor particular.

En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia
de Java para la instalación: hay usarios que no quieren instalarse
ninguna otra versión que la que ya tienen.

Esto provoca mucho quebraderos de cabeza para usuarios que se instalan
Autofirma sin leerse las instrucciones, acabando con instalaciones
rotas - no es intuitivo para el usuario instalarse las dependencias
manualmente.

Para conciliar esto utilizamos los virtual packages de
Debian: se supone que un paquete que da la funcionalidad
de un JRE 11 debería de declarar en la sección Provides: del paquete que
aporta java11-runtime.

Si no hay ningún paquete que ya provea al sistema de un runtime de Java
compatible con las versiones 11 o 17, se instala default-jre, versión >= 11.

Nótese que para que dpkg tenga conocimiento de esa instalación previa de
Java, debe de haberse instalado también con dpkg o apt. Según de cómo de
acomodador se quiera ser a los usuarios con su instalación custom
de Java fuera de dpkg, esto podría ser un breaking change para ellos. En
mi opinión, este es un uso menor, viendo la cantidad de comentarios de
la comunidad al respecto, como veremos.

Así se resuelven muchos problemas de instalación:
- un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el
  posteador)
- resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto
  gracias a una aclaración indicando su problema con las dependencias.
- closes ctt-gob-es#258, que simplemente pregunta desconcertado.
- En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema
  instalando Java de Oracle.
- En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o
  no de Autofirma varía de versión a versión.
- close ctt-gob-es#259, el issue mencionado al principio de este commit message.
- tenemos un tutorial/explicación y todo en ctt-gob-es#302

También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora,
que sufre de exactamente lo mismo. De hecho:
- ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java
  headless (el log errores menciona java.awt, abstract window toolkit).
  Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario
  en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no
  headless.

Referencias:
https://wiki.debian.org/Java - sección Understanding Java Virtual
packages names.
La misma idea de usar virtual package names surge en
varias preguntas de StackOverflow:
- Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme
- Depender de Java pero sin ser estricto en versiones
  https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency
  y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
LucasFA added a commit to LucasFA/clienteafirma that referenced this issue Nov 4, 2023
Exige la existencia de alguna librería de Java >= 11 sin exigir
ninguna versión o proveedor particular.

En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia
de Java para la instalación: hay usarios que no quieren instalarse
ninguna otra versión que la que ya tienen.

Esto provoca mucho quebraderos de cabeza para usuarios que se instalan
Autofirma sin leerse las instrucciones, acabando con instalaciones
rotas - no es intuitivo para el usuario instalarse las dependencias
manualmente.

Para conciliar esto utilizamos los virtual packages de
Debian: se supone que un paquete que da la funcionalidad
de un JRE 11 debería de declarar en la sección Provides: del paquete que
aporta java11-runtime.

Si no hay ningún paquete que ya provea al sistema de un runtime de Java
compatible con las versiones 11 o 17, se instala default-jre, versión >= 11.

Nótese que para que dpkg tenga conocimiento de esa instalación previa de
Java, debe de haberse instalado también con dpkg o apt. Según de cómo de
acomodador se quiera ser a los usuarios con su instalación custom
de Java fuera de dpkg, esto podría ser un breaking change para ellos. En
mi opinión, este es un uso menor, viendo la cantidad de comentarios de
la comunidad al respecto, como veremos.

Así se resuelven muchos problemas de instalación:
- un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el
  posteador)
- resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto
  gracias a una aclaración indicando su problema con las dependencias.
- closes ctt-gob-es#258, que simplemente pregunta desconcertado.
- En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema
  instalando Java de Oracle.
- En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o
  no de Autofirma varía de versión a versión.
- close ctt-gob-es#259, el issue mencionado al principio de este commit message.
- tenemos un tutorial/explicación y todo en ctt-gob-es#302

También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora,
que sufre de exactamente lo mismo. De hecho:
- ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java
  headless (el log errores menciona java.awt, abstract window toolkit).
  Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario
  en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no
  headless.

Referencias:
https://wiki.debian.org/Java - sección Understanding Java Virtual
packages names.
La misma idea de usar virtual package names surge en
varias preguntas de StackOverflow:
- Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme
- Depender de Java pero sin ser estricto en versiones
  https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency
  y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
LucasFA added a commit to LucasFA/clienteafirma that referenced this issue Nov 4, 2023
Exige la existencia de alguna librería de Java >= 11 sin exigir
ninguna versión o proveedor particular.

En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia
de Java para la instalación: hay usarios que no quieren instalarse
ninguna otra versión que la que ya tienen.

Esto provoca mucho quebraderos de cabeza para usuarios que se instalan
Autofirma sin leerse las instrucciones, acabando con instalaciones
rotas - no es intuitivo para el usuario instalarse las dependencias
manualmente.

Para conciliar esto utilizamos los virtual packages de
Debian: se supone que un paquete que da la funcionalidad
de un JRE 11 debería de declarar en la sección Provides: del paquete que
aporta java11-runtime.

Si no hay ningún paquete que ya provea al sistema de un runtime de Java
compatible con las versiones 11 o 17, se instala default-jre, versión >= 11.

Nótese que para que dpkg tenga conocimiento de esa instalación previa de
Java, debe de haberse instalado también con dpkg o apt. Según de cómo de
acomodador se quiera ser a los usuarios con su instalación custom
de Java fuera de dpkg, esto podría ser un breaking change para ellos. En
mi opinión, este es un uso menor, viendo la cantidad de comentarios de
la comunidad al respecto, como veremos.

Así se resuelven muchos problemas de instalación:
- un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el
  posteador)
- resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto
  gracias a una aclaración indicando su problema con las dependencias.
- closes ctt-gob-es#258, que simplemente pregunta desconcertado.
- En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema
  instalando Java de Oracle.
- En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o
  no de Autofirma varía de versión a versión.
- close ctt-gob-es#259, el issue mencionado al principio de este commit message.
- tenemos un tutorial/explicación y todo en ctt-gob-es#302

También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora,
que sufre de exactamente lo mismo. De hecho:
- ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java
  headless (el log errores menciona java.awt, abstract window toolkit).
  Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario
  en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no
  headless.

Referencias:
https://wiki.debian.org/Java - sección Understanding Java Virtual
packages names.
La misma idea de usar virtual package names surge en
varias preguntas de StackOverflow:
- Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme
- Depender de Java pero sin ser estricto en versiones
  https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency
  y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants