Skip to content

Comments

Instrucciones de instalación de paquete en Fedora#268

Open
Peque wants to merge 1 commit intoctt-gob-es:masterfrom
Peque:readme
Open

Instrucciones de instalación de paquete en Fedora#268
Peque wants to merge 1 commit intoctt-gob-es:masterfrom
Peque:readme

Conversation

@Peque
Copy link

@Peque Peque commented Jun 27, 2022

Hay varios "Issues" relacionados con la instalación y configuración de Autofirma en Fedora. Añadir algo de información en el README podría ayudar a nuevos usuarios y reducir el número de incidencias abiertas.

@LucasFA
Copy link

LucasFA commented Nov 3, 2023

Técnicamente la documentación está toda en un repositorio con toda la documentación junta, aunque entre que está muerto, la documentación parece desactualizada y está todo en formato Word 2007 pues...

Por lo que veo de tu commit en rpm también falta la instalación de Java - mi caso es basado en Debian pero también pasa lo mismo. Desconozco el funcionamiento de los los instaladores, más allá de que son básicamente scripts de shell ejecutados como root. Opino que lo ideal sería arreglar esto ahí directamente, declarando la dependencia, pero sin instalar la dependencia sin avisar al usuario, que podría ser problemático.

LucasFA added a commit to LucasFA/clienteafirma that referenced this pull request 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 pull request 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 pull request 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

Successfully merging this pull request may close these issues.

2 participants