fpc
LOGS
<@james:fedora.im>
16:01:48
!startmeeting fpc
<@meetbot:fedora.im>
16:01:53
Meeting started at 2024-05-23 16:01:48 UTC
<@meetbot:fedora.im>
16:01:53
The Meeting name is 'fpc'
<@james:fedora.im>
16:02:01
!topic Roll Call
<@conan_kudo:matrix.org>
16:02:03
!hi
<@zodbot:fedora.im>
16:02:06
Neal Gompa (ngompa) - he / him / his
<@tibbs:fedora.im>
16:02:22
Hey.
<@carlwgeorge:matrix.org>
16:02:29
!hi
<@jsteffan:fedora.im>
16:02:31
!hi
<@zodbot:fedora.im>
16:02:36
Carl George (carlwgeorge) - he / him / his
<@zodbot:fedora.im>
16:02:36
Jonathan Steffan (jsteffan)
<@james:fedora.im>
16:02:37
!hi
<@zodbot:fedora.im>
16:02:41
James Antill (james)
<@tibbs:fedora.im>
16:08:40
Hey friends, I have to apologize but as my home was right in the middle of the path of that bizarre storm in Houston last week, I just got power back last night and have not had much time to get up to date on FPC things this week.
<@james:fedora.im>
16:10:16
No, problem ... I don't think there is anything urgent atm.
<@james:fedora.im>
16:10:32
daMaestro: Did you turn up for a specific issue/PR?
<@jsteffan:fedora.im>
16:10:36
i have one item if there is no other agenda
<@tibbs:fedora.im>
16:10:52
Fortunately there was no significant damage to my house.
<@jsteffan:fedora.im>
16:11:00
yup. i'm blocked on multiple packages moving forward, with multiple upstream tickets opened i'd like to be able to report back and close to be able to move forward
<@james:fedora.im>
16:11:48
Can we help?
<@james:fedora.im>
16:11:58
How can we help?
<@tibbs:fedora.im>
16:12:01
It's the vulkan thing.
<@jsteffan:fedora.im>
16:12:13
i need a decision on https://pagure.io/packaging-committee/issue/1365
<@jsteffan:fedora.im>
16:13:02
i'm not a policy wonk, just trying to get things packaged and working in fedora -- been working closely with upstreams to get things in shape based on our policies and this one is still unclear/undecided
<@decathorpe:fedora.im>
16:14:10
!hi
<@decathorpe:fedora.im>
16:14:10
sorry for being late
<@zodbot:fedora.im>
16:14:12
Fabio Valentini (decathorpe) - he / him / his
<@jsteffan:fedora.im>
16:14:47
from what research and discussions i've been able to have, the general consensus is "that's how it works" ... so it seems the best action to take is updating the fedora policies to reflect this and provide clarity for upstreams and packagers
<@jsteffan:fedora.im>
16:15:13
i just guessed at what some policy language could be -- so i look to this group to actually write it :-)
<@decathorpe:fedora.im>
16:15:20
daMaestro: can you clarify this maybe? looks like you missed my question in the ticket > What I still think is very weird is that the libraries NEED to be in the default loader search paths, but they MUST not be dynamically linkable? How does that fit together? Are the Vulkan / OpenXR loaders "abusing" the default loader search paths for a different mechanism?
<@jsteffan:fedora.im>
16:17:18
Fabio Valentini (AFK 🤒): my understanding is that they do NEED to be in that location due to historical design decisions. based on dave's comments, even if we did make a policy to move them, we'd have to add that path to the default *anyways*. i didn't answer because i didn't feel it was my place to evaluate that design decision, i'm just reporting on it :-)
<@carlwgeorge:matrix.org>
16:19:04
I don't think that's accurate. When you put them in a subdir, you don't add that to the default path, you load them for just one program via an ld config file, IIRC.
<@jsteffan:fedora.im>
16:19:33
for normal case, yes. for vulkan/openxr, it's not
<@jsteffan:fedora.im>
16:20:25
from my non-technical evaluation (i.e. statements made and documentation reading), the loaders were initially designed to use the default loader path and that requirement persists still
<@james:fedora.im>
16:21:07
My understanding is that the users of the library just say dlopen("foo.so") ... so foo.so needs to be in the default path.
<@carlwgeorge:matrix.org>
16:21:28
> As an additional complication, some software generates unversioned shared objects which are not intended to be used as system libraries. These files are usually plugins or modular functionality specific to an application, and are not located in the ld library paths or cache. This means that they are not located directly in /usr/lib or /usr/lib64, or in a directory listed as a library path in /etc/ld.so.conf (or an /etc/ld.so.conf.d/config file). Usually, these unversioned shared objects can be found in a dedicated subdirectory under /usr/lib or /usr/lib64 (e.g. /usr/lib/purple-2/ is the plugin directory used for libpurple applications).
<@carlwgeorge:matrix.org>
16:21:42
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
<@james:fedora.im>
16:22:21
It does unclutter /usr/lib and stops people linking against the library ... but it's not normal plugin things.
<@jsteffan:fedora.im>
16:22:31
via the vulkan and openxr loaders, yes (as in users don't dlopen() directly in their applications
<@decathorpe:fedora.im>
16:22:32
sorry for not being clear - I didn't want an evaluation of anything, just an answer to "is this the case or not"
<@james:fedora.im>
16:23:39
That makes it sound like they could just change what the loaders do and fix everything.
<@jsteffan:fedora.im>
16:23:58
i believe it to be the case yes. this is based on the response from the mesa team (fedora) and PR rejections from upstream (monado)
<@carlwgeorge:matrix.org>
16:24:33
Do we actually know for a fact that the ld.so.conf.d approach can't work for this? Or are we just taking upstream at their word?
<@james:fedora.im>
16:25:23
I'm mostly in the *shrugs* stage ... we can mostly just ignore it all as historical bagage. Not sure we need to put something directly in policy, but if so I'd word it that way "certain old packages need to ignore the normal policy, so you can if you are one of them"
<@james:fedora.im>
16:25:56
I'm pretty sure you could use that to fix it, but people don't want to change.
<@james:fedora.im>
16:26:18
And, again, it only fixes /usr/lib clutter and stops random apps. linking to those libs.
<@carlwgeorge:matrix.org>
16:27:36
My preference would be that established subdir approach, absent actual evidence that it breaks the functionality of the program
<@decathorpe:fedora.im>
16:27:40
if this is indeed the way things work, I'm okay with saying "historical baggage, nothing we can do about it without massive disruptions"
<@tibbs:fedora.im>
16:29:10
I agree. There's a lot of stuff that we would ask to be changed if it were possible, but so often we're years late.
<@jsteffan:fedora.im>
16:29:31
there is a comment that newer openxr loaders handle multi-arch correctly now, but the old ones just load everything and evaluate if they are the right ELF arch
<@jsteffan:fedora.im>
16:31:47
so i've been chasing getting a single upstream (monado) to move it to a private directory and that opened the can of worms. we can obviously do whatever packaging policy we want, but then we are carrying downstream changes for the entire vulkan/openxr ecosystem and will be different than other distros (i would not expect others to approve the same self-inflicted workload)
<@jsteffan:fedora.im>
16:32:59
based on the quick response from the mesa folks (fedora), it seems like getting those packaging changes through would be wasted effort -- but that's just what i took from the ticket comments and those could be easily mis-read
<@carlwgeorge:matrix.org>
16:34:15
How much of a workload is it? We're not talking about a patch that needs to be maintained and rebased over time. Putting the files in a subdir and having an ld.so.conf.d file is pretty low maintenance.
<@carlwgeorge:matrix.org>
16:35:10
Unless of course that approach truly is incompatible with the software, in which case I'm fine with an exception.
<@carlwgeorge:matrix.org>
16:35:59
Basically I'm at "try the subdir way and see if it works", then we can make an informed decision
<@conan_kudo:matrix.org>
16:36:37
I am also at the point of just trying something and seeing how it works.
<@conan_kudo:matrix.org>
16:36:59
We could keep going back and forth on this forever, and I'd rather err on the side of doing something and getting stuff out the door.
<@conan_kudo:matrix.org>
16:37:46
the ldso conf file should probably be part of some vulkan-filesystem package or something
<@conan_kudo:matrix.org>
16:38:03
that way it becomes part of the search path early and influences automatic ldconfig runs
<@jsteffan:fedora.im>
16:40:07
i'm also not sure how much of an all-or-nothing prospect moving things is at this point. it could be the best approach is incremental.
<@jsteffan:fedora.im>
16:41:28
so, thinking through a first test, moving to a private subdir for unversioned SOs, while also adding ld.so.conf.d configs... what does it get us? seems like only filesystem layout
<@jsteffan:fedora.im>
16:41:46
it doesn't prevent incorrect linking against those, because they remain in the default path
<@james:fedora.im>
16:42:21
There are different paths for loading and linking ... ld.so.conf is just loading.
<@carlwgeorge:matrix.org>
16:43:12
Also, if you don't install the packages, it's not in your loading path
<@jsteffan:fedora.im>
16:43:50
for the specific and isolated case of the monado-vulkan-layer, i was able to to move it without issue. when we jump to a systemwide policy, we bring in all of vulkan and that will be a lot more effort. i'm also being sensitive to the direct feedback that upstream gave, i don't want to complicate collaboration there and make my efforts harder/futile
<@jsteffan:fedora.im>
16:45:13
specifically for openxr, it seems the loader has been improved to support what it seems like everyone's preference is here; i have not done any evaluation of the vulkan loader. my understanding is that it'll do what you configure it to do
<@carlwgeorge:matrix.org>
16:46:03
Upstreams aren't always fans of changes distros make. If we believe the change is beneficial for us and causes no harm, then it's worth pursuing in spite of upstream dislike.
<@conan_kudo:matrix.org>
16:47:10
also, sometimes upstreams change based on what we experience and report
<@jsteffan:fedora.im>
16:47:23
part if this request is to document what we see as the benefit, and documenting that we are not just bikeshedding
<@carlwgeorge:matrix.org>
16:47:27
Getting things merged upstream is of course preferable, but that requires upstreams to be willing and not super rigid
<@conan_kudo:matrix.org>
16:47:30
we're in the business of integration, which means we can offer expertise and experience they don't have
<@conan_kudo:matrix.org>
16:48:06
in this case, we're kind of stuck in a no-win situation unless enough things change upstream
<@conan_kudo:matrix.org>
16:48:49
and perhaps what we do tips things over the edge to get fixed upstream, who knows?
<@jsteffan:fedora.im>
16:48:51
agreed. i'm working diligently on that across the XR ecosystem -- it's slow going but making progress. the vulkan layers is still the big unknown for me so that's why i've asked the FPC to define a policy, and i'll follow that
<@decathorpe:fedora.im>
16:49:35
to be honest, if we're going to make a system-wide change to move stuff to subdirectories, that might qualify as big enough to warrant a Change proposal
<@jsteffan:fedora.im>
16:50:50
i don't feel qualified to argue one way or another, so i'd need someone else to do the change proposal :-)
<@carlwgeorge:matrix.org>
16:51:15
A change proposal for something that packages already do? For a package that is still in review?
<@decathorpe:fedora.im>
16:52:01
no, I mean moving stuff in mesa and other packages that provide vulkan / openxr plugins
<@decathorpe:fedora.im>
16:52:37
out of all of us here, you're likely the *most* qualified though
<@jsteffan:fedora.im>
16:52:40
well, another one identified was sssd, and i didn't scan all of fedora, just what's installed on my system -- there are likely other non-vulkan/openxr drivers/layers that would be impacted
<@jonathanspw:fedora.im>
16:52:54
!hi
<@zodbot:fedora.im>
16:52:58
Jonathan Wright (jonathanspw)
<@carlwgeorge:matrix.org>
16:55:40
daMaestro: my suggestion would be to send a pr to the guidelines with what you think the policy should look like, and then we can iterate on that
<@james:fedora.im>
16:58:07
Anything else before the end of the hour?
<@james:fedora.im>
17:00:36
!endmeeting