On 4/26/23 18:31, Richard Brown wrote:
On 2023-04-26 03:43, Simon Lees wrote:
On 4/21/23 20:45, Richard Brown wrote:
On 2023-04-20 13:10, Simon Lees wrote:
There we have nice graphical tools for handling the flatpaks, like GNOME Software. No typing anything, just pressing pretty buttons.
Does this also handle rpm's? I am generally unfamiliar with it as an openSUSE user who has access to yast and doesn't use Gnome (other then in lightning talks to show its useability issues :-P) i'm not that familiar with it.
In the MicroOS Desktop we have removed all rpm handling from GNOME Software - This is one of the reasons it runs liked greased lightning now :)
However before then, we did a number of experiments, especially around using dnf/microdnf (which has a much more robust packagekit backend) and extending that backend to support Transactional Updates by adding libtukit support.
This fell apart though, mostly because libtukit (quite rightly) only provides the generic distribution-neutral functionality to do transactional-updates. Distro specific logic, like handing the openSUSE way of doing kernel updates and bootloader/initrd generation isn't there at all.
Was this related just to Transactional Updates or would a system otherwise updating with a more traditional zypper / dnf also have these issues? If not then we could drop those no rpm patches for products that don't use transactional updates.
So would it be a better base for a hybrid solution then yast? and would upstream accept contributions? One other thing we found with Grassy Knoll is the dependency stack for anything Gnome related becomes very large very quickly and how / what we get from SUSE is still pretty unclear at this point. Having said that GDM has similar issues and i'd like to solve them there because its significantly better then lightdm in many applications.
Well, despite giving the idea of 'hybrid' graphical package management a chance, in the context of the MicroOS Desktop I actually LOVE where we've ended up.
In that OS, we WANT to encourage people to use Flatpaks as a first class citizen for graphical apps. For commandline apps or graphical apps that aren't flatpaks, we have rpms installed using regular ol' zypper inside distroboxes.
Messing around with packages in the host OS is really a last resort if the above two don't work, and in that context making people use transactional-update is just fine.
If you want my opinion, there is no better solution for a transactional, read-only root Desktop.
If people disagree with my world-view though and really want to do something in this area, the best way forward would be resurrecting the dnf/microdnf-libtukit-packagekit integrations and extending them so they're feature complete with transactional-update.
At this stage I know of maintainers who are happy to submit there Tumbleweed packages to a "Leap 16" because in many cases this isn't significant effort but don't really want to go to the effort of learning to make flatpacks however that ends up happening. So from that perspective having both might be the best solution. Or alternatively if its a relevantly simple to rebuild whatever flatpak's SUSE creates for there desktop as rpm's we could consider rpm only to be the official way for those packages even though 3rd party rpm's are becoming more popular and may help fill some gaps in the package list if the number of maintainers is less. So atm hybrid is probably going to wind up being the best solution. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B