[Feature/Question] desktop role(s)?

[ITwrx]

Is there a technical reason that transactional update is not offered during installation for the desktop roles? Or devs just haven't gotten to desktop(tumbleweed) yet?

I'm of the understanding that microOS has transactional update capability, but since that is largely designed for micro services, maybe that's not the best option for someone who expects to need more than flatpaks or something? I saw this presentation in the opensuse conf 2019 vids

https://www.youtube.com/watch?v=ASSkQH9kNa0&list=PL_AMhvchzBaeJiFMaZ3WsH7wt5ZXchUQ0&index=4

and that sounds good for users with limited/no need to tinker, but transactional update for desktops with tumbleweed proper, sounds good for other desktop users. Or maybe people are just supposed to use the standalone microOS with transactional update and tumbleweed packages as needed?

sorry, i'm seeing seemingly conflicting info and not sure what the current state and expected trajectory on this stuff is.

thanks

[ITwrx]

i installed the transactional-server role and then added the gnome pattern as a pseudo transactional-desktop role and there are some issues.

--i can install additional repos, but i'm not sure how i might install the signing keys as the normal way (zypper, IIRC) fails due to RO filesystem. I can still install software from those new repos using transactional-update, but with warnings about the keys.

--when i install software from the new repos; how to designate that it should do a vendor change? for some packages "it" (sorry i don't remember what component exactly) asked and allowed me to do a vendor change for some packages, but i don't think i changed all the ones i needed to, b/c i wasn't able (or didn't know how) to designate it during the install of those packages and ffplay still can't play my h264 rtsp stream (the packages in question were multimedia from packman repo).

edited to remove unrelated issue. leaving the rest in case it's of use. i reinstalled with normal TW for now.
thanks

[laenion]

--i can install additional repos, but i'm not sure how i might install the signing keys as the normal way (zypper, IIRC) fails due to RO filesystem. I can still install software from those new repos using transactional-update, but with warnings about the keys.

You can configure ZYPPER_AUTO_IMPORT_KEYS to add the keys to the RPM database permanently (see https://kubic.opensuse.org/documentation/man-pages/transactional-update.conf.5.html#ZYPPER_AUTO_IMPORT_KEYS).

--when i install software from the new repos; how to designate that it should do a vendor change? for some packages "it" (sorry i don't remember what component exactly) asked and allowed me to do a vendor change for some packages, but i don't think i changed all the ones i needed to, b/c i wasn't able (or didn't know how) to designate it during the install of those packages and ffplay still can't play my h264 rtsp stream (the packages in question were multimedia from packman repo).

For package installations / updates you can just use the usual zypper options (i.e. --allow-vendor-change or --from) after the pkg ... command. For up or dup it's currently not possible to add that option, you'd have to use https://en.opensuse.org/SDB:Vendor_change_update#Allowing_Vendor_change_in_general instead here.

As for the general usability of transactional-update on a desktop system: You can just install it anytime, it doesn't require a read-only system ;-) I'm using this myself to do larger updates or when I simply don't need an update to be applied immediately. Just be aware that any changes you are doing to the root file system until the reboot will be lost.
The question is whether you want to use a read-only root file system (which is what the Transactional Server role does) as a desktop system (which is what @sysrich's talk was about). In my opinion that doesn't make any sense currently, because you don't want to reboot to e.g. get your Firefox security update applied. To be useful this will imho require an alternate approach, which could be the approach Richard was talking about, but technically nobody is holding you off you from installing a desktop on a read-only file system - and we did that in the past. If something doesn't work this should be considered a bug.

[sysrich]

In my opinion that doesn't make any sense currently, because you don't want to reboot to e.g. get your Firefox security update applied

I have been very clear that the only way I see a Transactional Desktop being viable is using something like Flatpaks for user applications like Firefox

So, I'd appreciate it if you stopped speaking badly of your own update stack given it paints an invalid usecase as a something people should be thinking about..

[sysrich]

The question is whether you want to use a read-only root file system (which is what the Transactional Server role does) as a desktop system

In my opinion this is the only viable option. Having it as a read-write root filesystem means the system is at a permenant risk of changes occurring during the period after an update but before a reboot, and while those changes would take effect at runtime, they'd be immediately lost upon rebooting.

The whole appeal of a transactional desktop is that it will move from one known, defined state to another with less variance. If people want a system which can change while it's running, they can get that from the traditional way of doing things without the potential confusion of changes applied after an update disapearing when that update takes effect.

[ITwrx]

@laenion Thanks for the information. I already reinstalled the normal openSUSE b/c i needed to stop playing around with stuff i didn't know how to use and get back to work. :) Depending on how a transactional-desktop role shakes out i may try it again later and will keep your comments in mind (or the email section of my brain anyways). :)

@laenion @sysrich as far as not being viable for frequent/security updates, i don't think this is a big problem for some/many people. What i'm thinking i would like to do is set updates to run for a particular frequency (nightly/weekly) along with rebootmgr. The aim is a more secure/dependable auto updating desktop. People who want their security updates swiftly can choose nightly update+reboot, or can apply immediately and deal with the reboot. I don't think that price is too high.

edited to remove off topic monologue. :)

Thanks