Instalacion autofirma en rocky linux 8.5 green obsidian #258
Comments
|
Si te funcionará en rocky lo desconozco, lo que si te puedo decir es que necesitarás java 8 como mínimo. Con openjdk-11 funciona bien. |
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
HOla,
me he bajado el fichero AutoFirma_Linux.zip
de la web https://firmaelectronica.gob.es/Home/Descargas.html
este zip tiene dentro el fichero autofirma-1.7.1-1.noarch_FEDORA.rpm
la pregunta es, que debo instalar antes de este rpm ? java ? cuantos paquetes de java ?
Me va a funcionar ese paquete de fedora rpm en rocky ??
saludos !!
The text was updated successfully, but these errors were encountered: