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 <ku...@suse.com> 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) >
