Hola:
He comprobado que discover si tiene en cuenta los programas que se instalan desde yast2 y en viciversa, no los muestra (yast2) ; aún así ¿ hay independencia entre las dos? .
Según zypper no las hay.
Ahora bien los ejecutables de linux ( al contener independiente del sistema todo lo necesario para su ejecución) y poder asociar sus pacth a el lanzador de aplicaciones , ¿ hay alguna forma de indicar al sistema que están instalados ? (ya que su existencia no aparece, ni en yast2, ni en discover) .
RPM es el gestor de paquetes de varias distribuciones. Tanto Discover como zypper y Yast lee su base de datos localizada en /var/lib/rpm/ por lo tanto es la referencia de los ejecutables instalados en tu gecko
Toda aplicación y/o programa que no se instale usando archivos rpm no aparecerán en Discovery, Yast, zypper. Eso me pasa cuando compilo los programas fuentes, pero se puede localizar los ejecutables con comandos como whereis, which, locate, find…
Lo que no se es, si instalas programas usando Flatpak, AppImage y similares te aparecerán o no en Discovery, Yast y zypper como instalado (cosa que dudo), @karlggest te lo puede decir, ya que lo usa.
Ya más en serio, HAVER. Como todo en openSUSE o en Linux en general, depende.
tux@mipc~:> sudo zypper se discover
[sudo] contraseña para root:
Actualizando servizo 'NVIDIA'.
Actualizando servizo 'openSUSE'.
Obtendo os datos do repositorio...
Lendo os paquetes instalados...
S | Name | Summary | Type
---+-----------------------------------------+-------------------------------------------------------+--------
| aws-sdk-java-discovery | AWS Java SDK for AWS Application Discovery Service | Paquete
i+ | discover6 | Software store for the KDE Plasma desktop | Paquete
i+ | discover6-backend-flatpak | Flatpak Backend for Discover | Paquete
i+ | discover6-backend-fwupd | fwupd Backend for Discover | Paquete
i+ | discover6-backend-packagekit | PackageKit Backend for Discover | Paquete
i+ | discover6-lang | Translations for package discover6 | Paquete
i+ | discover6-notifier | Update notifier for KDE Software Manager | Paquete
| eclipse-p2-discovery | Eclipse p2 Discovery | Paquete
| jakarta-commons-discovery | Jakarta Commons Discovery | Paquete
| jakarta-commons-discovery-javadoc | Javadoc for jakarta-commons-discovery | Paquete
| kdsoap-ws-discovery-client-devel | Development files for kdsoap-ws-discovery-client | Paquete
i+ | libKDSoapWSDiscoveryClient0 | WS-discovery client library | Paquete
| netdiscover | A network address discovering/monitoring tool | Paquete
| python310-azure-mgmt-springappdiscovery | Microsoft Azure Springappdiscovery Management Clien-> | Paquete
| python311-azure-mgmt-springappdiscovery | Microsoft Azure Springappdiscovery Management Clien-> | Paquete
| python312-azure-mgmt-springappdiscovery | Microsoft Azure Springappdiscovery Management Clien-> | Paquete
tux@mipc~:>
Esta es una instalación básica en Tumbleweed (+ Plasma 6, naturalmente). Los discover6-backend- son los sistemas con los que trabajará Discover. En este caso vemos tres: para Flatpak (eso, los flatpaks que tan poco te gustan), packagekit (el sistema de actualización que en openSUSE usa libzypp) y fwupd (actualización de firmware). Eso significa que puede instalar y actualizar paquetes de esas tres fuentes.
Dicho esto, en cuanto a instalación, Discover es “para aplicaciones”. Esto significa que si buscas en Discover libqt no te devolverá nada, mientas que zypper se libqt te devolverá una retahíla de cosas. Si quieres actualizar, eliminar o instalar librerías concretas tendrás que hacerlo con Zypper.
De hecho, puedes seleccionar una aplicación -digamos VLC- y elegir si quieres el flatpak o el de repositorios de openSUSE:
En la esquina superior derecha podéis ver cómo se selecciona la fuente. En principio puedes instalar un programa desde la fuente de openSUSE (en mi caso, Tumbleweed) y desde el repositorio flatpak que sea, incluso puedes instalar ambas versiones a la vez(1).
En Leap 15.5 y supongo que en Leap 15.6, con Plasma 5 por defecto, para actualizar paquetes hay un applet que usa packagekit y que en mi experiencia funciona bien y lo hacía también en Tumbleweed. Eso también implica que no creo que haya un backend de paquetes de openSUSE para Discover en Plasma 5. En tal caso Discover solo manejará flatpaks.
En cuanto a snap, se supone que hay alguna utilidad por ahí para gestionarlos. appimage es un simple ejecutable y como tal no incluye nada aunque supongo que también abrá alguna utilidad para ellos(2)
(1) pero no a la vez: instalas una, y luego cuando sea instalas la otra. No he probado si puedes instalar una mientras instalas la otra.
(2) en los repositorios hay un demonio llamado appimaged que supongo que hará este tipo de cosas:
Descrición :
appimaged is a daemon that handles registering and unregistering AppImages with the system (e.g., menu entries, icons, MIME types, binary delta updates, and such).
The package comes also with appimage.validate CLI tool to verify signature of AppImage files.
Tanto discover como yast2 ,zypper y pakagekit , están interactuando con rpm , tanto en parches como programas (desconozco si discover, mantiene el historial, cat /var/log/zypp) .
Los Appimage , no son reconocidos por esas aplicaciones; y por el sistema, quedo en la duda de lo comentado por @karlggest , sobre ese demonio .
Lo que si se puede hacer, es un enlace simbólico y a hechos prácticos, es reconocido, tanto en el lanzador de aplicaciones, como favoritos o en barra de tareas (pero no como programa descargado, pero si a nivel de ejecución ) .
En consola, no sabría decir si es correcto, por estas razones :
Ejecuto el comando compgen y muestra, que es parte del contenido, pero no es correcto (muestra krita en versión 5.2.3, cuando en realidad tengo la versión 5.2.6 ; ahí desconozco si puede ser fallo del demonio o si es un fallo en el primer registro del enlace simbólico que hice ) .
Por lo pronto aclarado este tema, igualmente desconozco si hay algunas utilidades, para ello .
Más que integrarse más en el sistema lo que hace Discover (Descubrir) es ocuparse mejor de las aplicaciones -pero es muy lento aun!!.
YaST y zypper hacen un trabajo muy bueno manejando ficheros .rpm. Eso, por supuesto, deja fuera todo lo demás.
Por su parte, Discover se encarga de los ficheros .rpm y los flatpaks.
Por ejemplo, no es probable que @DiabloRojo tenga nada instalado de esta forma ni intención de instalar algo a corto plazo, así que le resultará indiferente usar Descubrir, zypper o YaST para instalar programas. Es más, como Descubrir sigue siendo un tanto lento y no puede buscar o instalar librerías, pues cualquiera de las dos opciones tradicionales le resultará más conveniente. Es cierto que yo apenas instalo algo como flatpak para probar aquí y allá, así que en realidad podría arreglármelas sin él, pero como nos han quitado el applet de Plasma 5 para las actualizaciones lo uso para por lo menos no tener que estar mirando si hay actualizaciones y tal.
Pero en Kalpa es la forma de instalar software. Aunque es posible usar rpm en Kalpa, es absurdo: la idea es no tocar el sistema base en absoluto o al menos lo menos posible. Lo mismo vale para Aeon, no en vano son sistemas gemelos, pero en lugar de Descubrir la herramienta de Gnome es Software. De hecho en estos sistemas la instalación al acabar instala automáticamente alguna cosa como Firefox como flatpak al reiniciar el sistema. Y para cosas como LibreOffice también deben instalarse así.
Hola: lento si es, pero por ahora veo que no da fallos.
Ademas muestra tanto los programas de zypper y yast, y los de flatpack (lo indica con un flatpack y un pequeño icono) también ; incluso un mismo programa aparece dos veces uno de flatpack y el otro me supongo que de zypper o yast .
Estoy usando los dos, ya que hay programas que no hay en uno y si en otro proveedor ( o una es de versión superior y el otro no) .
En definitiva aprovecho lo que nos dan.
Gracias y un saludo.
Me parece bien que aproveches lo que haya, pero danos tus impresiones y/o valoraciones de los sistemas de instalacion.
En mi caso, prefiero tenerlo todo centralizado con la base de datos de paquetes RPM e instalar otras cosas con compilaciones de fuentes o script de instalación como calibre. En primer caso me deja los ejecutables en la carpeta /opt y en 2º caso en mi carpeta de usuario de /home y, así, no contaminar el sistema.
Igual debería usar Flatpak si me dejara los ejecutables en /opt o /home/mi_usuario, pero no me ha quedado claro donde lo deja. ¿Alguien sabe cual es la carpeta destino?
PD: Según esto, parece que las instalaciones de usuario se almacenan en ~/.local/share/flatpak/ , y las aplicaciones de todo el sistema y el contenido base se almacenan en /var/lib/flatpak/ . ¿Alguien puede confirmarlo y dejarnos la salida ls -al de ambos directorios para echar un vistazo?
Suele cambiar , en sus propiedades , no se si el desktop y la ruta del enlace, me parece que también cambia y lo hace desde otro sitio (tampoco que recuerde no crea un org kde)
Y me da que el enlace simbólico lo hace a través de flatpack, ahora no puedo confirmarlo, ya que pase los programas a yast y a zypper .
Cuando instale krita , el creo otro directorio y lo puso ahí , había ido a ¬/.local para hacer los cambios del programa de krita y no funcionaban (registro del que había instalado antes, o posiblemente el que creo el appimage así que lo busque y era en : /home/frank/.var/app/ dentro de ese puso a krita (lo he quitado, por que uso el de appimage) por lo pronto , era en ~/var/app y ahí creaba el directorio del programa.
HP-OMEN:~ # tree /home/frank/.var
/home/frank/.var
└── app
1 directory, 0 files
Al mirar las propiedades del icono, en donde pone ejecutable, me parece que ponía otra cosa, como que lo redirigía desde ahí , tendré que instalar uno para ver como era , (ya que ahora no estoy seguro) .
En el lanzador de aplicaciones , no se busca por propiedades, si no que hay que buscar lo donde pone ( cuando pulsas con el botón derecho del ratón sobre el icono del programa ) editar aplicación .
Instale 2 y donde pone apunta a , muestra :
/var/lib/flatpak/app/com.boxy_svg.BoxySVG/current/active/export/share/applications/
En aplicación ; la ruta del programa es : /usr/bin/flatpak (lo mismo para los dos programas) :
HP-OMEN:~ # tree /usr/bin/flatpak
/usr/bin/flatpak [error opening dir]
0 directories, 0 files
Ahí no hay directorio flatpack , (de eso es el error que indica) , es un ejecutable flatpack
Creo que eso fue lo que no me gusto (en su momento) ¿ese comando es el encargado de ejecutar las aplicaciones ? (en vez de ejecutarlas directamente) .
Lo que si cambia son los argumentos (cada uno lleva el suyo) y en el nombre también cambia, creo que pueda ser el mantenedor o la organización , como algunos pone org kde o algo por el estilo , en estos son : com.boxy_svg.BoxySVG y el otro io.gitlab.theevilskeleton.Upscaler .
Resumiendo , eso es lo único que no me ha gustado o no lo entiendo bien, por lo demás los programas funcionan bien .
Me olvidaba de los desktop en estos son :
/var/lib/flatpak/app/com.boxy_svg.BoxySVG/current/active/export/share/applications/com.boxy_svg.BoxySVG.desktop
Puedo hacer algo mejor. Voy a instalar el “célebre” navegador Vivaldi. En mi sistema, Discover instala por defecto “como administrador”(1). Entonces es de esperar que esté en /var:
En realidad no. Simplemente hay algunos paquetes que se instalan como administrador (para todas las personas usuarias del sistema) y otras que se instalan en la cuenta usuaria por la persona que las instala. Con las del sistema pasa justo igual, solo que como normalmente las instalas como administrador no te preocupas por ellas. Pero fíjate que la configuración sí va en la cuenta usuaria.
Es más: desde un punto de vista teórico /var es un sistema de ficheros de lectura y escritura y /usr es de solo lectura. Te recomendaría buscar un hueco para probar cosas como Aeon/Kalpa.
Eso es una decisión personal.
Va: permitidme describir nuestro sistema favorito como “bibliocéntrico”. Eso es porque tenemos muchas librerías que proporcionan los servicios que usan las aplicaciones que queremos instalar y es una de las razones por la que las aplicaciones en sí mismas necesitan poco espacio.
Esto es complejo y para que funcione nuestra distribución usa
rpm como paquetes para distribuir el software. Esos paquetes no son diferentes a hacer un paquete con tar + gz, por ejemplo, y pueden ser librerías compartidas, programas, ficheros de configuración…
Zypp como sistema para administrar las dependencias entre paquetes.
Como recordáis, zypper se encarga de comprobar que si un paquete llamado PaqueteA necesita una librería llamada LibreríaA se asegure de que se instala también para satisfacer esa dependencia. Típicamente la instalación de PaqueteA hará que el sistema instale también el paquete LibreríaA o algún paquete que contenga dicha librería.
Esto requiere asumir muchas cosas. Que el nombre del paquete es el mismo, que la ruta donde se instalan las cosas es la misma (/etc/Vivaldi o /etc/vivaldi?), que los paquetes se llamen igual… Si yo desarrollo una versión de LibreríaA para TW pero le llamo PaqueteB al paquete rpm, la persona que empaquete (y que compile) PaqueteA tiene que saber que el paquete que necesita en este sistema se llamará PaqueteB en lugar de LibreríaA como puede ser en otros sistemas. Es por eso que no todos los paquetes de Fedora, ni mucho menos, pueden ser reutilizados en un sistema como Tumbleweed: deberían usar los mismos nombres, la misma estructura de ficheros, las mismas versiones…
Flatpak usa la misma estructura en cualquier sistema operativo, así que todo funciona con facilidad. Podemos ver la estructura tracicional con las carpetas etc (configuración), bin (binarios), etc, en el ejemplo con Vivaldi:
tux@mipc:/var/lib/flatpak/app/com.vivaldi.Vivaldi> ls x86_64/stable/865431766e981ee229d189def3589e0f8735c04881343b63770593992c783eb9/files/
bin etc include lib libexec manifest-base-1.json manifest.json share vivaldi
Como veis es bastante similar a lo que estamos acostumbrados. Siemplemente en lugar de instalar los ficheros de configuración en el lugar “general” los instala en su propia carpeta. Los programas con instaladores en /opt suelen hacer algo similar, y podrías tener (no lo he comprobado) algo como:
tux@mipc:/opt/Vivaldi> tree
bin
└── vivaldi.sh
│
etc
└── vivaldi.conf
(...)
Si antes he dicho que Leap o Tumbleweed son “bibliocéntricos”, Flatpak es “aplicacioncéntrico”. La idea es que incluya sus propias librerías, de forma que jamás tendrás un conflicto de versiones aquí. Al mismo tiempo Flatpak también se encarga de la administración en todos los sentidos.
Por ejemplo, las aplicaciones de Flatpak tienen su propio sistema de permisos. Si yo instalo Vivaldi y voy a Configuración del sistema → Permisos de aplicaciones → Vivaldi y le retiro el permiso para navegar no navegará. Puede que no me sea muy útil en ese caso
De hecho Aeon/Kalpa no activan el cortafuegos por defecto, ya que se espera que añadas las cosas como Flatpak o usando contenedores de Podman (Docker).
En mi opinión no hay nada como rpm+Zypp. Si zypper te parece lento, puedes usar dnf. Pero ese sistema de paquetería es sencillo, eficiente… la pregunta es si hay gente para mantener todo lo que hay y sobre todo para portar todo lo que no hay.
Sobre Descubrir específicamente. Los más veteranos puede que recordéis kpackage, que era una aplicación sencilla para KDE (antes de ser Plasma!) para manejar paquetes rpm. Pues los escritorios siempre han intentado añadir software de su escritorio para hacer que usarlo en una distribución u otra fuera lo más parecido y fácil posible. Desde hace tiempo se metieron en Descubrir y la dotaron de soporte para Flatpak. En las distribuciones basadas en rpm es capaz de manejar los paquetes .rpm, con lo cual puedes buscar tu aplicación e instalarla desde la fuente que prefieras.
(1) En Kalpa por lo menos viene para que puedas instalar el software como persona usuaria no administradora. Aquí hablan de eso.
Me ha quedado claro que las aplicaciones las mete en un lado X (en lugar de un /usr/share/etc pues en /var/etc) y que lleva sus propias librerías para que funcione por lo que no hace falta instalarlas desde otro lado.
Pero las configuraciones no me queda claro. Todo apunta (por lo que he visto en tu bloque de código) a que una aplicación de sistema las meterá en un /var/etc. ¿Mete la configuración o no en $HOME?
Porque si nos ponemos a mirar, Plasma (por ejemplo) es una aplicación de sistema instalada en algún sitio pero la configuración del Autostart (por ejemplo) está en el directorio oculto $HOME/.config/autostart.
Imagino que Firefox sería una aplicación de usuario y estaría en $HOME/var/etc y la configuración en el directorio oculto $HOME/.mozilla. ¿O no?
Lo que me hace pensar que las aplicaciones personales (Firefox y tantísimas otras) pasarían a ocupar espacio en /home en lugar de en /. ¿Es correcto?
Contesto a tus puntos
1.- Las aplicaciones instaladas como paquetes RPMs se meten en varias carpetas como /var/etc/, /bin, /sbin, etc… pero la configuración se crea en el $HOME del usuario
2.- Correcto
3.- Si Firefox lo instalas como aplicación de usuario dentro de tu $HOME, también es correcto. Tengo Calibre instalado en mi $HOME y eso que es un programa pesado.
4.- Correcto.
A veces me extiendo tanto para ser más claro que al final no me explico muy allá. Tal vez usando varios posts, uno para cada asunto concreto… El caso:
La configuración personal siempre va en /home/[cuenta]/ . De hecho, ahora se tiende a que vaya en ~/.config con algunas excepciones cosa de sus desarrolladores pero que claramente se pasan la idea por …ejem, no digáis tacos. En cuento a Flatpak, si echo un vistazo a mi carpeta Home con el ejemplo de Vivaldi:
En realidad, la diferencia entre flatpak y rpm es que el primero instala casi todo lo relativo a una aplicación en la carpeta de esa aplicación. En este caso, /var/lib/flatpak/app/com.vivaldi.Vivaldi si lo instalas como administrador, ~/.local/share/flatpak/app/com.vivaldi.Vivaldi para la persona usuaria.
¿Has dicho casi todo? Bien, hay cosas que necesitan compartirse. El caso más claro es el fichero programa.desktop para el acceso directo, pero también iconos y demás. Por ejemplo, las instalaciones de administrador lo guardan en:
tux@mipc:/var/lib/flatpak/exports/share> ls
applications dbus-1 icons metainfo mime
tux@mipc:/var/lib/flatpak/exports/share
La carpeta equivalente pero para personas usuarias regulares es: $HOME/.local/share/flatpak/exports/share/
No. De hecho, puedes tener instalado Firefox desde los repositorios rpm y a la vez como flatpak. La carpeta para la configuración de cada persona usuaria es $HOME/.var/app/[nombre de aplicación]/config.
Y es un asunto no menor. Si tú instalas Firefox como flatpak y después instalas un paquete, yo qué sé, firefox-extensiones.rpm con zypper, lo más probable es que Firefox no vea esas extensiones porque espera que estén en otra carpeta.
Sí, o como siempre, depende. No hay ninguna razón para que no puedas montar una partición para $HOME/.local/share/flatpak en el dispositivo que prefieras.
Prácticum:
Como ejercicio, puedes usar Descubrir para instalar algún programa, o el propio Firefox desde comando como se indica aquí. Y puedes probar la diferencia respecto a una instalación sin privilegios.
El primer comando añade el repositorio para uso de la persona usuaria sin privilegios de administrador. El segundo instala el programa sin privilegios de administrador. El tercero siemplemente lanza el programa.
En lugar de usar el terminal, puedes usar su acceso directo buscándolo en el menú pero cerciórate de que no es el acceso al Firefox que ya tienes como rpm.
Luego podrás dar una vuelta por /var/lib/flatpak (si lo instalas como administrador o desde Descubrir) y por .local/share/flatpak y .var/app/ para ver cómo se organiza todo esto.
Con mi tocho post me refería todo el rato a preguntas acerca de exclusivamente a paquetes flatpak ya que parece que instala tanto paquetes de sistema como de usuario (en ningún caso menciono RPMs con lo de paquetes).
En estos momentos lo que tengo más claro de todo (y si no, me corregís) es que:
Paquetes flatpak de sistema (todo lo referido al sistema operativo y escritorio) como Dolphin (quizás) se instalan en /var/lib/flatpak
Paquetes flatpak de usuario (navegadores, multimedia, etc etc etc) se instalan en $HOME/.var/app/ y sus configuraciones en $HOME/.var/app/[nombre de aplicación]/config.
Lo que sigo sin tener del todo claro es si la configuración de un paquete flatpak de sistema (como Dolphin, creo) se mete en $HOME/dondesea o dónde. Quiero imaginarme que es en $HOME/dondesea porque si no es un truño.
Mis preguntas es para acabar de entender a los paquetes flatpak (Dolphin1 por ejemplo) que por lo visto traen sus propias librerías y que se actualizan cuando haya un flatpak nuevo que lo necesite del paquete sistema en cuestión (Dolphin2 por ejemplo) creo que lo tengo claro.
Aunque eso me hace pensar en una posible redundancia de librerías si cada paquete de sistema (Breeze, Akonadi, etc, etc) las lleva (o igual Plasma es todo 1 paquete en sí y no necesita repetir Qt y KF).
No creo que vayas a instalar Firefox o Dolphin o Akonadi… usando Flatpak porque lo tienes en los repos principales, algunos como parte de Plasma.
Entiendo la explicación de mi compañero de que quieras probar como usuario algún programa, como Vilvadi u otro, sin necesidad de instalarlo como paquete RPM.
Mi idea es: si algún programa no lo encuentras en los repos principales o quieres probarlo como usuario, merece la pena instalarlo con Flatpak.
En mi caso, uso Calibre instalado en mi $HOME con un script, igual merecería la pena instalarlo como Flatpak porque como RPM de un repo comunitario deja mucho de desear (cuantos menos repos mejor). Lo mismo digo con respecto a algunos programas que tengo instalados en /opt desde codigo fuente y no los he actualizado por vagancia.
Corolario: voy a usar Flatpak cuando algún programa no este en los repos principales.
Cuando instale krita, el creo un directorio en /home e instalo allí el programa. (creo un /.var/app/krita) .
flatpack que puso en la raíz ( /usr/bin) , creo que pueda ser un demonio (no me refiero a el directorio) .
Aunque tienen discover los programas, temas,etc , no crea un historial (como zypper o soft de yast2) .
Resumiendo, sigo pensando lo mismo, para el que solo usa los programas y no administra el equipo, me parece bien, pero para el que lleva un control, veo que está un poco esparcido (me recuerda cuando se creo plasma y aún se mantenía la base runtime de kde, algunos rc, estaban en user y no en /.config (hasta que ordenaron el tema y los pusieron en su sitio ) .
El programa de flatpack, se puede editar en su enlace y pasarlo junto a los demás /usr/bin y el enlace desktop, en applications (se que hice una prueba y funciono , pero no se si lo tiene en cuenta a la hora de actualizarlo ) . (lo hice por que me dio la sensación de que tarda un poco mas en arrancar, al final la diferencia no es mucha) .
En /opt , no instalo nada, pero los drivers de las impresoras, los instala ahí :
HP-OMEN:~ # du -x -h --max-depth=1 /opt
1.2M /opt/epson-printer-utility
5.3M /opt/epson-inkjet-printer-escpr2
3.3M /opt/brother
9.7M /opt
Esto lo puse mal al principio, luego en la edición lo corregí pero igual no lo puse muy claro. Las aplicaciones del usuario, sin privilegios de administrador, van en $HOME/.local/share/flatpak.
En la carpeta .var lo que va es la configuración. Si Firefox tiene .mozilla/firefox y dolphin tiene .config/dolphinrc, el flatpak de Firefox usa .var/app/org.mozilla.firefox
Eso es una cuestión importante e interesante. Por un lado, es posible tener partes de la aplicación de turno que se compartan, y por tanto podría hacerse lo mismo con una librería. Pero en realidad no es la idea.
Por ejemplo, una aplicación como Dolphin requiere una serie de comandos básicos del sistema (eso siempre está instalado), un entorno gráfico operativo (incluso si no es Plasma, al menos un servidor gráfico y algún cliente gráfico), las librerías QT y las librerías KDE. Entiendo que puedes instalar un entorno gráfico que contenga las librerías QT y KDE, que dependa de que existe un sistema gráfico funcional y las herramientas básicas del sistema. Y que entonces puedes añadir Dolphin.
O un desarrollador podría decidir usar unas versiones concretas de QT y KDE y hacer un paquete que las proporcione. Así alguien podría instalar esa versión de Dolphin incluso precisamente porque esté hecho con esas versiones de esas librerías.
Si esto es así, será el desarrollador o empaquetador quien lo decida, y en esto se parecería a crear un paquete rpm.
¿Y cómo se traduce esto?
La idea que usa Flatpak es usar entornos de ejecución. Cada aplicación o grupo relacionado de aplicaciones tiene el suyo. En cada grupo de ejecución están disponibles las librerías, ejecutables y demás elementos necesarios para ejecutar cada programa. Así, he instalado Vivaldi con su propio entorno de ejecución, y he hecho lo mismo con Firefox. Aquí una descripción de Vivaldi, donde ves que usa un entorno de ejecución “general” para aplicaciones: freedesktop
Según lo entiendo yo la versión del entorno de ejecución (runtime-version) determina ese mínimo común. Cada entorno de ejecución será en general redundante, y cada versión del mismo será redundante a su vez.
Por ejemplo, yo tengo estos entornos de ejecución:
(además del de Firefox, está en /home).
Y éstas son las aplicaciones que tengo o he instalado para curiosear la aplicación o incluso para probar el propio flatpak/Descubrir:
rnote (editor de notas de estos que están de moda ahora por markdown), Flatseal (editor de configuración de flatpak), cliente para spotify, Vivaldi (que he instalado para las pruebas en este hilo), Memorize (buscando aplicaciones que me pudieran ser útiles al dar formaciones), un monitor de sistema que tengo que desinstalar porque creo que ya no tiene soporte, Vym (herramienta para hacer mapas mentales o chuletas gráficas), outlook para linux (para ver si se parecía para las formaciones tb aunque creo que la he desinstalado), Podman Desktop (una herramienta gráfica para manejar contenedores con Podman), MasterPDFEditor (un editor de PDF pero no veo que mejore mucho a Draw), Avidemux!!!, Cockpit client (cliente de Cockpit del que tengo un hilo en el foro), FreeCAD beta! (a ver si sacan la 1 de una vez, aunque la preferiría en repositorios), Gaphor (modelado UML), Jitsi (vídeoconferencia, reuniones etc.), Calligra (la suite ofimática de KDE que dio herramientas tan buenas como Krita, pero cuyos procesador de textos y hoja de cálculo son manifiestamente mejorables), Musescore (editor de partituras) y OnlyOffice (versión de escritorio de dicha suite ofimática).
Ya os digo que la mejor forma de entenderlo es usarlo. Yo juraría que en Plasma 6 me pide la clave de administrador para actualizar y no entiendo por qué (no debería hacerlo). O sea, sí, supongo que es porque son instalados como administrador, entonces hay que actualizarlos así, pero eso es un bug como una catedral. Debe hacerse justamente igual que con los rpm. Por otra parte hay un par de servicios de systemd para actualizar esto automáticamente sin que pregunte.
Mejor no, en tal caso lo suyo es instalar todo Plasma de esa forma.
Es un buen término medio y más o menos lo que hago yo (aunque tengo un montón de repos por buenas causas)
Las buenas causas: instalas algo para probar y te olvidas de que está allí.
Eso es la configuración. Mira en este post más arriba la descripción completa.
Tampoco lo necesita. Como más o menos cada paquete trae lo suyo, ¿qué más da? todo funciona (o no funciona entonces lo que tienes es que quitarlo porque es que algo está muy mal).
Recuerda que flatpak es para programas.
No sé si tarda más en arrancar, pero no es necesario hacerlo. Flatpak ya se cuida de eso.
Eso es porque son privativos o al menos los trata como tales, seguramente descargados de la web. Que yo sepa hay drivers libres para ambas y yo suelo preferirlos (pero no así sus escáners!).
Una cosa más: Flatseal es una herramienta para configurar flatpaks. Yo lo tuve que instalar para configurar bien el cliente de Cockpit. En Configuración del sistema de Plasma podéis ir a Permisos de Aplicaciones en la sección Seguridad y Privacidad, donde os lista todas las aplicaciones que tenéis instaladas de esta forma y su correspondiente configuración. Flatseal tiene alguna opción más de las que salen ahí y para el dichoso cliente me hizo falta una de ellas.
[edito]
Cuando seáis mayores podemos hablar de Distrobox
Muy interesante el post pero sigo sin tener respuesta a:
Supongo que esa pregunta que hago es bastante absurda ya que si Flatpak está pensado para aplicaciones, éstas suelen ser de usuario.
Ahora mismo, Discover (en mi sistema se llama Discover, no sé por qué alguno lo llama Descubrir) me está informando que hay una nueva snapshot de TW, la 20241010:
Contestando a tu 1ª pregunta: Se puede instalar Dolphin ya que esta en Flathub para probarlo. ¿Dónde se instala y donde esta la configuración? Mi compañero ya te ha dicho las rutas.
Sobre la snapshot, deberías saber que bastantes RPMs que incluye un script que se ejecuta cuando se instala el paquete (fíjate lo que hace el paquete de NVIDIA-G06); en este caso supongo que se encargara de hacer una snapshot.
Alguien comentó en Mastodon que para cambiar de idioma había que cambiar la variable de entorno y lo instalé para probar el Flatpak a ver qué hacía.
En $HOME/.var la configuración personal.
Ni sí ni no, esto es Linux y cada distribución sigue sus reglas incluso para cada producto. Que yo recuerde Kalpa lo trae como de usuario (o tal vez pregunta?) pero en Tumbleweed viene como de administrador.
Actualizar, claro, y supongo que usa LibZypp, pero en todo caso es similar a usar el applet de escritorio en Plasma5. Se genera el snapshot y demás.
Por cierto, puedes añadir los repos de usuario y ya puedes instalar como usuario, tampoco tiene más.
Y ya puestos, Descubrir es el nombre en castellano pero en ocasiones se usa sin traducir, no sé por qué (es más, yo lo tengo en gallego!). No sé si es errata de tu sistema o política de nombres de la traducción castellana.
