Meeting started at 2026-05-28 16:01:20 UTC

The Meeting name is 'fpc'

Hello.

Hey

!hi

!hi

I'm in this shitty internal meeting so this is a nice distraction

!hi

#1539, #1540, #1541 PRs should be ready to discuss

There's also issue #1538 about Openstack

!hello

gotmax23: Maxwell G (gotmax23) - he / him / his or they / them / theirs

!hi

Carl George: Carl George (carlwgeorge) - he / him / his

I filed https://github.com/fedora-infra/maubot-fedora/issues/152 about the broken `!fpc` command, but no response yet

!hi

Fabio Valentini: Fabio Valentini (decathorpe) - he / him / his

Any questions here? Basically, we already allowed including pre-generated JS and CSS but the Guidelines were still unclear about it. This PR fixes that.

Any questions here? Basically, we already allowed (well, FESCo did, I guess) including pre-generated JS and CSS but the Guidelines were still unclear about it. This PR fixes that.

Yeh, seems fine to me.

It still amazes me that this is allowed, but that wasn't a decision of this committee. And certainly the document shouldn't contradict itself or policy.

For churchyard's question ... I assume it was MUST in the srpm, but now I'm not sure.

Shall I push the big blue button or does anyone have other objections?

I wonder if the forge has anything we could use for voting in tickets.

Wasn't the problem that the guidelines for generated code in "What can be packaged" was less strict than the explicit rule against JS and CSS?

yes

yes, that's what I thought too?

or is it the other way round? I'd rather just drop special casing for JS / CSS ...

tbh, I don't know why we shouldn't have the JS/CSS being compiled during package build at all times

This is specifically about pre-generated/minified CSS and JS. FESCo grnated a special exception.

when did we do that?

I think this is *less* strict than the general Guidelines

https://pagure.io/fesco/issue/3269 is for CSS

We can use emoji's on a comment ... but PRs have mostly been "better to merge and fix later, unless anyone shouts"

https://pagure.io/fesco/issue/3177 is for JS

hmm, we probably need to force the inclusion of a justification document for "hardship"

I'm fine with doing formal +1 comments like FESCo does, but I don't think that' the FPC's current procedure?

otherwise it's going to be "I dun wanna" and that's not good enough

especially now that it screws with core applications to the fedora distribution

The goal of this PR was not to change any existing Guidelines but to clarify what had already been agreed on and just not entered into the text in a clear way

so you're saying that we need to revisit this at the FESCo level? ;)

sure, but it's equally valid for us to reconsider the nature and validity now that the circumstances have changed

I guess the requirement about including an explicit comment about what's the "hardship" is supposed to help here

hardships need to be justifiable

seems reasonable, yeah

otherwise we're going to get more functionally unfixable packages

if you can't explain why you can't self compile you can use it to justify anything

we've already had this problem twice with cockpit and once with anaconda

heh, doubly so for critpath packages like this

I'm fine with discussing making things stricter again, but 1) that should be separate from this PR and 2) NodeJS packaging in Fedora is terrible and we should make sure the stricter Guidelines are actually practical first

Making a distinction for critpath packages seems too fragile to me because that list is always changing

so... should we file to revisit this and then just accept the PRs for now?

that's why I'm saying circumstances have changed that make pregenerated JS+CSS less tenable overall

it's some of the same people involved anyway

critpath packages merely expose the problem with more regularity

accepting a clarification to fix the current guidelines is fine with me, but I agree that this should be revisited

i'm +1 to merging this as-is for the current state of things, and also +1 to revisiting if/when fesco changes the policy

keep in mind that ordinarily fesco will just kick it back to us 😅

I wonder whether we should treat pre-minified JS / CSS functionally the same as binary blobs - both are not "patchable"

if we do that, the ban on such blobs would kick in

which puts us back to this conversation again

I see you see where I'm going with this ;)

:D

but if there's going to be the insistence that apps are written with web technologies, we are probably going ot have to assert that the same packaging flexibility _must_ exist for such apps

right now, they don't if they do pre-minified sources like cockpit framework apps do

basically, we can merge this PR, but I think we will wind up changing all the SHOULDs to MUSTs

basically, we can merge this PR, but I think we will wind up changing all the SHOULDs to MUSTs shortly afterward

web technology is a mistake

Does someone want to file a ticket to discuss further? It probably should go to the mailing list.

well, not necessarily, but the mistake was accepting that web code is different from local code

which is not true

And not sure if we can decide to unchange this rule or if FESCo has to do that

packaging rules are fully delegated from fesco to us

fesco can override us selectively, but they generally won't

Right, but FESCo made this decision for us here for reasons that are not entirely clear to me

Again, I do think someone needs to work on improving the NodeJS packaging ecosystem in Fedora before making guidelines stricter. The current approach requires manually dealing with massive npm vendor tarballs to rebuild assets and those tarballs themselves can also include binary blobs.

So I don't think that approach is much better

Trying to move this forward ... does someone want to file a ticket somewhere?

Conan Kudo 😌: Not to volunteer you, but...

blech fine

I'll do it

gotmax23 gave a cookie to ngompa. They now have 207 cookies, 3 of which were obtained in the Fedora 44 release cycle

Do you want to merge the PR in the meantime or wait?

I think it's fine to wait, if we have a ticket to point to in the PR

I'm always of the opinion that the guidelines should reflect reality and policy, even if we want that to change. But maybe if it's going to change soon, the churn isn't worth it.

I think this one will be easier ;)

+1

🚢 it

Dito. this one.

The history here is such a mess.

But yes, +1.

is there an rpm document to point to about how these work yet?

Yeh, rpm macro hacks are slowly evolving into a language.

otherwise sure +1

https://rpm.org/docs/latest/man/rpm-macros.7#Macro_manipulation

+1 here also

I follow the rpm mailing list enough to have seen Panu post that there's no reason for our preference, anymore.

Okay ... what was the 4th thing gotmax23 ?

https://forge.fedoraproject.org/packaging/guidelines/issues/1538

oh dearie

In general I don't think groups need to ask us to add triggers.

yeah, especially if the paths are self-contained and owned

it's only if there needs to be a policy to document that it is necessary

and I think that's the _actual_ implication here

no ... though I am wary of adding anything that changes /usr at runtime depending on what packages are installed

openstack CLI plugins need to be packaged a specific way for his trigger

Yeah, that part I'm not a fan of

and yes, I think we probably need to ban such practices

And also this doesn't work in containers (such as toolbox), since it relies on systemd to generate the completions

This seems like a lot of trigger scripts for bash completion.

As a meta-thing, I do think that in general this kind of "trigger just tickles a unit file to run" thing is something that should be promoted.

Background: I thought was really wacky/potentially problematic and was worth discussing here so I suggested to the maintainer to file this

ehhhhhhh

ehhh, it's less good than you'd think

yeah it's a really strange upstream setup IMO

I have tried this pattern a few times with Fedora Asahi Remix and it's really hard to get right

I really don't like the creating arbitrary files in /usr/share just to trigger a filetrigger that triggers a systemd service part of this

I would say leave the systemd unit out

instead have a libexec program to run

I think it's better if there's a small number of those unit files that are audited by a lot of experienced people. Much less good if lots of random packages create unit files to do it.

I think the idea was that they wanted to run this as an unprived user. But I guess that can be done without systemd.

it makes it way more stable and reliable

I did work on the shell completions stuff a while ago and generally make an effort to ship them in packages, but this all just seems like too much to me

As an admin, hunting through rpm -q --scripts output to see how things work and how I can trigger those things manually is kind of a pain, so standardization is good.

Whether that's unit files or something else, I suppose, doesn't much matter.

Do filetriggers from other packages that apply to another package even show up in `rpm -q --scripts`?

iirc, triggers are a separate flag from scripts

I don't see why the bash completion can't pretend all the plugins are installed. Or even have some std. way for the plugins to expand the bash completion by dropping files somewhere.

yup, `--filetriggers`

Running programs to build the completion seems like the wrong approach.

It's all done through Python entrypoints, so the CLI code has to be executed with all the plugins installed to generate the completions

no, you need to query `rpm -q --triggers`

but to answer the question, the triggers show up in the package that owns them, not the package triggering them

well it's ~possible~ to generate completions dynamically ... it might just be *slow* :)

I think argcomplete works like that, but it seems this uses some other Python CLI framework I've never heard off and has to pre-generate the completions file with all the options

Anyway, I think this solution is really ugly, but I can't think of anything better because of how openstack's CLI and plugins are architected. So does anyone else feel strongly against this or should we just close the ticket?

Personally, I'd rather just include documentation telling users to run X command to generate completions locally and call it a day

i'm having flashbacks to something about using systemd units to avoid the need for scriptlets, in pursuit of making packages work better on atomic spins. my memory is failing me, does anyone else remember this? i wonder if there is a way to align these approaches.

man-db I think?

this is using _both_, so 🤷

Yeh, rpmostree etc. didn't used to run any scriptlets (not sure about current state).

I think that was fixed (to some degree ...)

So units etc. were a better approach ... but as you said, this uses both.

On the upside I guess it means the rpm transaction doesn't have to wait?

This uses a filetrigger to run a systemd unit which I think is also how man-db works

i'm sure this will all come back to me about 10 minutes after the meeting is over

But the filetrigger here requires that all openstack plugins create some arbitrary file in /usr/share to activate it

yeah the arbitrary file part is weird, and a divergence from the man-db approach

i guess the architecture of openstackclient prevents this, as i don't see a common plugin directory

yeah, it's all based on Python entry points

seeing as we're out of time, are we gonna put a pin in this and discuss again next week?

We are at time ... yeh, we could come back to it in two weeks.

seeing as we're out of time, are we gonna put a pin in this and discuss again next ~~week~~ meeting?

Or people could ask questions in the ticket too, I guess ;?

The great thing about the markdown std. is that there are so many to choose from ;)

Okay, see you all next meeting.