Hello everyone! I am not sure where to categorize this post so I put it as off-topic.
Crystal is an interesting programming language and I like to help package the language in openSUSE. Thanks to @straight-shoota for packaging the language in openSUSE!
So I made some changes in my branch project in openSUSE Build Service, and I think this will work:
- I made a dummy package called
crystal where it only
requires the latest package.
- The “latest package” is called
crystal1.7 and this package will obsolete any package from any given version
suffix e.g. 1.6, 1.5, and 1.4.
- This means, we can use either prebuilt crystal of a previous version from upstream to compile latest crystal version. Or even use the older versions built in openSUSE Build Service to build latest crystal using a conditions argument in the rpm specfile.
Links to my packaging methods below:
So why do I like to package it like this? I was inspired by how Rust is packaged in openSUSE, and I like this approach because this means we can test the compiler if it builds correctly on openSUSE Build Service.
Although, I kind of understand why @straight-shoota used that approach since making Crystal available for all platforms is an understandable goal. (I do think we can just use an if-else condition to check if we are packaging crystal for openSUSE with the
Let me know your thoughts if it is okay to do that.
Thanks @uncomfyhalomacro for working on improving the packaging.
I’ve had zero experience with creating neither RPM nor DEB packages, or OBS as a build system prior to setting up these repositories. So I very much appreciate to get some support to make things better.
- Making the
crystal a dummy that refers to the latest versioned package makes totally sense and is much easer IIRC we started with the
crystal package and the
crystalX.Y packages were added afterwards as a duplicate, so we ended up with the current setup and never changed it.
- Sounds good. It’s a bit weird to have to manage and grow this list explicitly, but it’s okay.
- Building natively is great because that allows enabling the interpreter which doesn’t work with the generic binary because it’s statically linked. This of course makes it more work for OBS, but I suppose that’s what it’s there for. Packaging just the generic binary from the official tarball was just a quick and easy solution and works well enough. But building is better, it just needed a bit more work to setup the dev environment. But that you already did, so thanks
I’m happy to roll out these changes for other distros as well, assuming they work or we can get them to work
I tried your package and noticed some issues:
Out of the box with
zypper install crystal it’s pretty much unusable.
We definitely need a linker to build any Crystal program. Hence usually
gcc is declared as dependency.
The standard library requires libgc and libevent for every program. Libpcre (or libpcre2 starting with 1.8) is also very commonly necessary, so I’d suggest to add their devel packages as
Other stdlib dependencies are libssl, libz, libxml2, libgmp and libyaml, but they’re only necessary when using specific parts of stdlib. So they definitely don’t need to be hard requires. Not sure if it makes sense to add them as recommendations.
Also recommendations seem to only work for
crystal. I guess they need to be specified directly on the package?