[bravetraveler]

With things like the OpenSUSE build system... I see this more as a one time cost

You write the spec files for the managers of choice; DEB, RPM, PKGBUILD, whatever

With that you parameterize the inputs. The version to build, where to get the sources, etc.

Maintaining these is... note your build/runtime requirements the same way you do while developing.

Once the specs are written the laborious work is finished. There are countless tools to make this less effort, eg: pyp2rpm and alien

I maintain packages through Fedora COPR, a similar system. These tools are my first pass at writing the spec for things I don't even own.

I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it.

This is a critical first step to being bundled in the distribution itself. You won't get maintainers if there's nothing to maintain.

[ilyt]

Pretty much. I've built a few for the internal stuff and it is essentially one time effort for DEB based platform.

Clowns at Red Hat do like to break manifest compatibility in the worst way tho, think "a macro with same name in new version now does something else". The idea of .spec file being whole manifest is... nice in theory, not in Red Hat execution. But then last time I did any for RHEL was at RH6/7 time, maybe it's better now...

But even in that case that's fixing few minor things every 3-5 years at worst. There is no excuse to not make your packages if you're actual serious developer, not some random hobbyist.

I do give a pass for apps that run as single binary as that while suboptimal is at least easy to work around.

[bravetraveler]

Oh you're right, that surprise macro dance is an absolute pain.

Being on Fedora I run into this a little more regularly than you would on proper RH these days, it's like the prerelease playground.

If you (or anyone) had things building fine for Fedora 36, they may not on 37. I forget which but one of the macros I repeat moved packages

One of these likely translates to a future Red Hat release

[mustache_kimono]

> I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it.

I've heard a lot about these systems, and, if they do what they promise, I think this is great. Exactly what is needed. I already do package and distribute my software. My comments are mostly directed at those who have a problem with those who don't, because that's a fine choice too. It can also be a fine choice for awhile. The problem is mostly one of attitude, we need less user entitlement re: packages. Packages are something I will get to if I want to, when I have the time, and if it interests me.

I would note there are other problems with the package manager ecosystem which make it ill-suited to packaging Rust apps, for instance. I am not an Arch user, but Arch really is leading the way here: https://wiki.archlinux.org/title/Rust_package_guidelines

[bravetraveler]

Thank you for the packages you do maintain!

I don't want to seem unappreciative for the work developers like yourself and others do; packages or not.

I'm not a developer, but a Linux/systems person who happened to learn packaging. Mostly because I got tired of building from source, and figured others were too.

As a maintainer it is easy for me (and others) to trivialize this, as compared to actually writing the much more complicated software. It's not right, and I think we could all use more understanding.

I see a meme that 'packaging is hard', and while very rigid/plain, it's not actually that tough.

Priority is another matter, I just don't want this notion of difficulty to unfairly sway that priority. Many of the concepts reapply, like languages. The tooling/services have improved a lot

I'm not too familiar with Rust, unfortunately. What would you say makes Arch stand out in particular?

How do you feel about Fedora? https://docs.fedoraproject.org/en-US/packaging-guidelines/Ru...