Hi Thorsten,
If I understand correctly, you're looking for a way to distribute sysexts such that they can be enabled/disabled, and they're updated in lock step with each other and the base OS. Is that correct?
If so, you're looking for Optional Features [1], which will release with 257
Best,
Adrian
On Thu, Oct 31, 2024, 07:16 Thorsten Kukuk <kukuk@xxxxxxxx> wrote:
Hi,
I'm currently working on integrating systemd-sysext in MicroOS.
For this I created several sysext images with different tools (e.g.
"gcc", "debug", ...) which I can add in parallel.
Which, besides some problems with SELinux and transactional-update, works.
Now the idea is to use systemd-sysupdate to update the sysext images,
but the implementation is very specific for "there is on OS, which
consists of several images, where the ones with the same version
belong together".
Example output:
Determining installed update sets…
Determining available update sets…
VERSION INSTALLED AVAILABLE ASSESSMENT
↻ 20.2 ✓ candidate
● 20.1 ✓ ✓ current+incomplete
19.1 ✓ installed+incomplete
17.1 ✓ installed+incomplete
16.1 ✓ installed+incomplete
15.2 ✓ installed+incomplete
That's not really helpful to see, what is the "gcc" and what is the
"debug" image or something else.
Are there any plans to support images with different names and version
numbers to make this usable with sysext images?
I would like to avoid adding image handling to zypper...
I'm using systemd from current git.
Thanks,
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)
