Meeting started at 2025-02-20 20:00:42 UTC

The Meeting name is 'ELN SIG 20 Feb'

The Meeting Name is now eln

!hi

Michel Lind (salimma) - he / him / his

!hi

Neal Gompa (ngompa) - he / him / his

!hi

Davide Cavalca (dcavalca) - he / him / his

!hi

Neil Hanlon (neil) - he / him / his

!hi

Troy Dawson (tdawson)

Happy thursday, all

welcome all, looks like we have a nice group today, let's get started

Conan Kudo you had left a comment about the systemd-sysusers situation (affecting both rawhide and ELN), anything that needs to be discussed?

I suspect we'll come back to this problem when rpm gains tmpfiles integration

tbh, we probably need to fix this for all the "standalone" tools

Has anyone looked to see how big of an issue it is in all of Fedora (not just ELN) ?

in that case, my question would be what value the standalone tools would still provide

they don't really anymore

unless you really want a tiny image

because then you don't have libsystemd-shared pulled in

~30K vs ~4M

ouch

(I'm not actually sure if it's 30K but it's definitely in that range)

does that include all the deps of systemd-shared?

not sure

IMO this just exposes the bigger problem we have with unconditional dependencies on host-only services

libsystemd is getting slimmed down in the future too with more dlopen usage, but there's probably a lot of slimming to do

I've seen it a lot with flatpaks, but other parts of the distro are just as affected

More dependencies need to be conditional on the kernel being installed I guess

I look at systemd as being the determining factor, because of init containers

because either an image will already have systemd to serve as PID 1 (bootable system or init container), or it won't (userspace container, toolbox, flatpak, etc.)

but getting to that point (both in approach and in implementation) will take time

Conan Kudo I guess we'll follow up in the ticket

anything else on this particular point?

the dlopen thing is more of a mask than a real fix

and we still don't have things wired up in rpm to deal with the dlopen metadata systemd makes

but yeah nothing else

any other new business to discuss?

ok, moving along

before we start going through tickets, anything anyone wants to raise first?

Nothing from me.

anything to discuss this week on the desktop background? there's been some activity in the ticket, and currently the vote is scheduled for next week

I didn't do the "ELN on Fedora background" because I agree with you.

I guess I should have said that in the ticket.

it's nice to have someone agree with me occasionally (iykyk)

doesn't look like there's been any progress on other projects dropping their dnf-4 dependencies

Conan Kudo was it PackageKit that you were going to look into?

yes

I can understand some of them giving priority to other things, but I'm a bit surprised about PackageKit and policycoreutils.

I'm hoping that with RHEL 10.0 wrapping up soon, that teams will start to look ahead again

Yep

it might help if the dnf5 documentation were better though

yeah

that's been the stumbling block for me

we've had the same problem with porting Content Resolver to dnf5

I asked them about it in my last meeting with them, I hope they are able to address it soon

it would be really nice if they could help/guide these particular projects with the porting

maybe they can't do it all themselves, but without the docs it's pretty hard for anyone else to either

anything else on this ticket?

so I find this one particularly interesting, and it also affects Fedora to some extent

the big question here is what sort of images/installations should be readily automatable with ansible?

the ansible dnf* modules require the corresponding python dnf* library (remember that ansible is written in and works with python)

I keep finding that ansible is everywhere.

Though, I have to admin, these shouldn't be in minimal containers.

in the dnf-4 era, anything with dnf would automatically have python3-dnf, because that was the implementation

but not so with dnf5

python3-libdnf5 is a binding, not strictly needed by dnf5 (the CLI)

i guess I will run into this in OpenStack-Ansible at some point

**ponders adding ELN as experimental in CI**

but we build our own images, so not directly comprable

so, whatever we want to be ready as an ansible host (iow a node that is controlled by ansible) will need a deliberate addition of python3-libdnf5

but what should be and what need not be?

Just to clarify, cuz I'm a bit confused. Will ansible not run without python3-libdnf5? Or is it just some of the plugins?

basically anything that needs to manipulate the system

well, packages, i guess

ansible.builtin.dnf, e.g., needs to be able to talk to DNF via python

Unless they are using dnf5 itself, like a real person would.

This is just me, but I'm looking at ansible and thinking "well ... do something about it."

right, but the question here is what kind of images/installations do users need to be managed by ansible, and which not?

e.g. what about the base (docker/podman) image?

I don't think containers need it

"cloud" instances, maybe? but it also feels like something that should/could just be a Recommends: on ansible

if it isn't already

a host doesn't need ansible-core to be controlled by ansible, it just needs python and certain python modules

Sorry, but that's the opposite of what I'm thinking. Ansible has known that dnf5 is c++ based for years. It's great that we are able to get python out of things so they are trimmed down and fast. And because they (ansible) aren't doing anything, we have to put extra stuff into the images just because they don't want to do anything.

Sorry, but it has to be said.

https://docs.ansible.com/ansible/latest/collections/ansible/builtin/dnf5_module.html

I've got two tickets asking me to take python out of my images, and then this one asking me to put it in.

That might be true, but let's not forget the conversation that we just had about the DNF5 api and the challenges therein with respect to adoption.

To be clear though, I think it's perfectly reasonable to _not_ ship it in the images, and for those who need it to: 1. install it; or 2. come join the SIG and maintain that image variant for their use cases

Ya ... and it seems reasonable for people to want it in. I wouldn't even have an opinion on this if it weren't for the two tickets I'm working on.

if people could put some input in the ticket, we have different viewpoints here (and that's great!), clearly this a bigger question that will need further discussion probably on higher levels

depending on what kind of images you mean, removing python might be premature

let's remove python _and_ add it to the repo excludes! 😉

I'll add something to the ticket, with links to my other tickets.

thanks, and anyone else's views are welcome here too, please chime in

but in the interest of time...

anything else to discuss today?

Oh, sorry for taking so much time.

I want to say that I've started on the Contenter Resolver / Extras stuff.

how's that going?

It's going to take a while just because it takes so long to do a run.

But the code is very well commented, so fairly easy to read.

do none of the in tree tests cover that case?

I haven't tried them yet ... I didn't think of them.

it doesn't need to be all of ELN+Extras, you just need a base config (e.g. a tiny subset of ELN, such as what goes into a base container image) and then an add-on config that has both runtime and build deps which are not in the base config

right now, you'd only get the runtime deps, the goal here is to get the build deps too

Yep, this last run I've taken a large chunck off ... but now that I'm looking at the test configs ... those are much smaller .... that might help speed things up.

Anyway, it's moving along. It's possible I can have signifigant progress next week.

looking forward to it!

one minute left, anything else?

thanks for running!

in that case, thank you all for coming today, and for the discussions. see you elsewhere until next week.