Meeting started at 2026-06-25 16:00:43 UTC

The Meeting name is 'fpc'

!hi

Hello.

!hi

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

Michel Lind ☘ UTC+1 ⏱️: Michel Lind (salimma) - he / him / his

!hi

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

!hi

Michal Schorm: None (mschorm)

Hey

[@mschorm:fedora.im](https://matrix.to/#/@mschorm:fedora.im) that's a brave name to have - None 😅

Reminds me of the guy with the NULL license plate in California

IRL little bobby tables

IDK, I should have "displayed name" set to my full name. Any idea where to change this "None"?

Hopefully costs Michal a lot less ;)

https://accounts.fedoraproject.org/user/mschorm/

Pretty sure this is reading FAS data, so go there.

!hi

there's also a privacy toggle that might prevent usage of the data set there.

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

Michal Schorm: I guess this is what you are here for? ;)

yup

In the spirit of a similar request for MariaDB few months ago

versioned packages have an automatic exception

yeah that should be fine, just request the package with `--exception` instead of a bug number

but if you want to have it in writing, +1 :)

this is documented somewhere, trying to find it...

Doesn't the `--exception` need accepted FPC ticket ?

https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_exceptions

Not if there's already an approved exception

But I think the wording was problematic here?

> The package is being created so that multiple versions of the same package can coexist in the distribution (or coexist between EPEL and RHEL). The package MUST be properly named according to the naming guidelines and ***MUST NOT conflict with all other versions of the same package***.

hm ... 🤔

good point

Should we remove that last part from the guidelines? Or grant a special exception here? Or something else?

for packages like Django and Python I think we use the normal review process instead of the exception

I'm confused about the reason for that part.

git blame is not telling me anything useful about that last clause, it's been there since it was converted from the wiki

yeah, I've kinda given up trying to git blame things in the guidelines for that reason

I would probably be in favor of changing the text here

My _guess_ is that it's trying to avoid problems like: X requires Y; user installs Y6.6; user installs X and it fails?

i'm fine just dropping it. the general guidelines already cover conflicts (should avoid if possible)

yeah I'm guessing it's "if it does funny things it needs full review"

too bad wiki history is harder to search

I can see how it'd be bad to conflict with a heavily required package, but at the same time I don't think many people want to run two versions of mysql.

Well, it has to be a different version of the same package

Michal Schorm: Either way, your review is excepted ;)

https://forge.fedoraproject.org/packaging/guidelines/pulls/1552

If nobody else wants to tweak the wording, I'm fine just dropping it and waiting to see what blows up as a result ;)

carlwgeorge has already given cookies to gotmax23 during the F44 timeframe

I do recall that we added this just to avoid weird issues.

Plus a general dislike of conflicts.

(Something that's since been lost, I guess.)

In many cases, it's unavoidable without patching upstream software

if you want to have multiple versions packaged

even on compat libraries where the main package can be parallel, the devel subpackage usually has to conflict

yeah

devel not conflicting is possible but it is a hard ask (and might require patching all the dependents, not fun)

Yeh, there are a couple of exceptions like GCC ... but in general it's probably not great.

At the time we wrote it we likley had very few versioned packages.

Do we want to discuss distro conditionals or NodeJS (again)?

"want"? probably not? :)

I really need to stop asking you questions that start with "want" ;)

as to nodejs - I think it makes sense to require stripping executables and package applications needed to build things from source in separate RPMs

FWIW There have been 9 new issues opened since our last meeting ... including the above mysql one.

(kind of obviously, since that is outlined in other parts of the guidelines ... but apparently this hasn't been applied consistently to nodejs packages?)

FWIW There have been 7 new issues opened since our last meeting ... including the above mysql one.

yeah, the tooling doesn't enforce it though, so I guess people thought it was okay/didn't realize

I'm not sure if this is better or worse than just shipping pre-built JS blobs and not trying to build anything at all...

I wonder how this even worked. are pre-built executables included for all architectures? or are those packages only built for x86_64?

I do think removing that exception probably makes sense for SPAs like Cockpit where the JS is a significant part of the package functionality, but this is probably not as important for copies of jquery in sphinx docs...

yes, they are built for multiple arches and uploaded to npm as separate packages I think 🤷

apparently this is a common practice

oh ew

well I'm all for not allowing that then 😂

https://www.npmjs.com/search?q=esbuild%2Flinux-

esbuild is at least packaged as a separate package now in Fedora

which I'm not even sure is technically allowed by the Guidelines that require bundling nodejs

and people want to package nodejs stuff, and there's no clear way to do it properly, and it's frustrating

absolutely :(

and now FESCo has a list of packages that don't follow this rule, and I'm not sure what to do about them

I guess the only viable options are: 1) Shrug and give up. 2) Get the ban hammer out ;)

another common build tool I think is https://github.com/rollup/rollup which now has rust components

3) deprecate

and do a Change Proposal to clean up

2.5: fix guidelines and tooling and banhammer for anything that doesn't get fixed?

I think I've found the glaring problem with option 3.

banhammer given enough time is fine, yeah

but we need to figure out some realistic guidelines

The NodeJS maintainers did acknowledge the problem and express willingness to fix things/accept contributions to the tooling on the devel thread

but someone needs to find time to work on it...

Yeh, this is mostly what I meant (what do you mean I can't just ban JS packages ;).

and the npm ecosystem isn't doing us any favors here

not if we want an installer

that's true...

if only I have more spare time I want to know how guix handles it

or Debian?

I remember they have a ranty talk about how bad some packaging ecosystems are

yeah but guix iirc has consistent tooling for generating packages in different language ecosystems

Debian... trust me, they don't :)

but both are good to study nonetheless, true

I just meant Debian generally has a stricter stance on bundling

Neal Gompa (Fedora): Might know.

But not here this meeting.

Like looking at Arch that builds everything with internet access enabled is probably not going to be very enlightening on how to solve our problem

Anyways, I guess we can keep this on our radar and hope something improves

Not sure what to do about the FESCo ticket. Retiring those packages if nothing gets fixed doesn't feel productive

But we don't really have much else

having a flag date might help

yeah but then we have to do something when we get to the flag date 😱

🤫 that's the idea

flag date driven development

FDDD

Shall we move on?

moveon.org

Sure

So I don't want to allowlist certain distro macros, but I also don't want Fedora to get flooded with PRs to add separate conditionals for every single downstream

I know that Azure linux has a tool to automatically set existing bconds/make other small changes

The original intent of this was to avoid having macros for suse and other RPM-based distros in Fedora packages.

is Conan Kudo 😌around? he is one of the few that maintain multi-distro specs

!hi

So even if %azurelinux or whatever isn't in the test bcond definition there, having the bcond at all is helpful

Conan Kudo 😌: Neal Gompa (ngompa) - he / him / his

I know when this comes up Jason ティビツ is usually the one who wants some wording so people don't try to do specfiles that can run on 666 different distros.

So even if %azurelinux or whatever isn't in the test bcond definition in Fedora, having the bcond at all is helpful

Because Fedora maintainers can't be expected to understand or test packages for those distributions.

if we have a preprocessor that can strip out the non-fedora parts it would be nice

already Fedora maintainers don't even test for the distributions we do offer builds

then as long as the spec is still valid we don't have to care about those

like if there are RHEL conditions, most Fedora maintainers in fact ignore them

Yeah, I don't want to allow conditionals for RPM distributions with completely different guidelines or macro systems

wait, what do you mean here?

yes

we at least make sure it builds, no

nobody has to do that

The only real issue is that maintainability just goes out the window if you have to account for and comprehend so many distributions just to fix a bug in a packages.

I encounter packages in Fedora where the package is broken on RHEL with the Fedora SRPM/spec

because it does bad things like conditionalizing patch lines

Or conditionalizing `Name:`

We should really make that not allowed...

yes I'm looking at you freeipa

and linux-system-roles

and I think there's more

conditionalizing patch application, sure, but patch naming, heck yeah that should probably be banned outright

there are many tortured packages in fedora that are either half broken or insane to review because of RHEL

it just bites you later

so I don't really buy any legibility or testability argument because people don't do it _now_

with the restrictions we have currently

I'm much more in favor of throwing out the distro conditional block and explicitly outlining where and how distro conditionals are permitted to be used

because frankly policing which dist macro is allowed or not is just a rabbithole of crazy

fyi, there are 95 rawhide spec files that reference suse_version

yeah, I do think that creates a legibility issue

suse is not derived from Fedora at all

so ban it completely? well if even Neal is in favor...

technically, it is currently banned

the suse thing is probably maintainers who also use OBS

like the toolchain packages have SCL macroization _just for RHEL_

so they like having One Spec to Build Them ALl

and that makes it completely miserable to look at

copr too

I would be open to encouraging separate ELN branches for this kind of thing

i brought this up a few weeks/months ago that reality doesn't match the policy, and it's hard to align them without an enforcement mechanism

the kernel spec is a special brand of crazy because it uses fedora conditionals because fedora is not the default case

when it changed to ark, fedora stopped being the default for the kernel package

But some RHEL maintainers in Fedora really insist on keeping ancient things (or just blocks of code not applicable to Fedora) in Fedora packages

that should have never been permitted

And it makes it really difficult for anyone else to work with

this is why I think the right approach is restricting what distro conditionals can be used for

and as someone who does multi-distro work, it's a lot rarer than you'd think to have to do any more than just wrapping BR lists

so, status quo as far as the policy? "only macros and conditionals for Fedora and EPEL" covers fedora/rhel/epel

well no

if it's for rhel but not epel, then it's out of policy

I would say that also covers centos at this point.

ie rhel core packages aren't supposed to have it

that's the strict reading

ie rhel core packages in fedora aren't supposed to have it

obviously we don't want to do that

but that's the strict reading

Well, I don't like these complicated RHEL conditionals, but I'm also don't want to have long bcond conditionals that explicitly disables test for every single downstream and is 200 characters long

I think %rhel is covered for packages in EPEL and in ELN

Well, I don't like these complicated RHEL conditionals, but I also don't want to have long bcond conditionals that explicitly disables test for every single downstream and is 200 characters long

i mean, that can just be an else condition for `%{defined rhel} && %{defined epel}`, no real burden there

again, my belief is that smithing for specific distro macros is just a crappy idea

I'm happy to propose a rule that provides multi-distro guidance

I tend to do the conditionals based on the underlying issues if possible

I'm happy to propose a doc that provides multi-distro guidance

like the Python version

otherwise there's too much craziness to guess which distro has which

I wrote one many years ago for $dayjob internal work and I could write a new one for Fedora

yes please, i can review and give feedback. lots of ideas for best practices rolling around in my head.

salimma gave a cookie to ngompa. They now have 210 cookies, 6 of which were obtained in the Fedora 44 release cycle

I think if you did a PR that changed it from talking about specific macros to just "things which have the same guidelines root" ... that might work?

sure

fun fact, that covers almost all rpm distros :P

SUSE reforked Fedora's packaging guidelines twice and realigned their packaging to be similar to ours years ago

i think removing the legibility guidance we have now won't affect things materially one way or the other, since this rule is already widely ignored

yes

Huh, I did not know that.

i do think we need to remove suse_version usage, as that isn't a downstream or related at all

I think the only RPM distros I know of that isn't rooted in Fedora packaging is ALT and PLD

To be fair that does make me a lot more open to allowing suse macros, either way.

they are Mandrake descendents that went their own way

yes, I actually helped implement some of it the second time

I've also brought things from SUSE to Fedora too in that process

the interface for the cmake macros came from openSUSE, even if the implementation is very different

and I'm working with the openSUSE guys to replace their implementation with ours

since ours are better :P

Having a distributed FS for `/usr` has seemed like a viable idea to me a few times ;)

but anyway, I'll work on a write up as a pull request

gotmax23 has already given cookies to ngompa during the F44 timeframe

james gave a cookie to ngompa. They now have 211 cookies, 7 of which were obtained in the Fedora 44 release cycle

let us know when you get suse to switch to dnf 😛

carlwgeorge gave a cookie to ngompa. They now have 212 cookies, 8 of which were obtained in the Fedora 44 release cycle

oh man, you should see my talk tomorrow on livestream at oSC

Cool, we are at time ... so unless anyone has anything else that needs to be talked about very quickly then we should end.

https://events.opensuse.org/conferences/oSC26/program/proposals/5143

the talk earlier today (https://events.opensuse.org/conferences/oSC26/program/proposals/5142) by SFaulken already announced Kalpa Desktop is switching to DNF5

Are "transactional systems" like ostree?

no

btrfs

I dream of making a centos hyperscale image with it

maybe when things are less insane at work

Conan Kudo 😌we have one year after c9 EOL and before we're busy with c11 :)

Shawn is interested in helping :)

he's in the #btrfs:fedoraproject.org room so you can ask him about it :)

On that note...