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.
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 %{suse_version} macro).
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
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 Required.
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 crystal1.7, not crystal. I guess they need to be specified directly on the package?
Yeah, I could’ve pinged you but kinda lost track of this as well.
I think it looks pretty good now
There are a couple minor details in the build instructions and requires that could be improved and simplified.
Not sure what’s the best way to move forward, do you have a suggestion?
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.
this means I have to update all the specfiles as well to put it as Recommends. I also just noticed that I missed crystal1.7’s correct deps so i need to update it as well. It should be fine. I can do it on the weekends.
As for the build, I don’t know much about other platforms such as Debian, but I believe I can do with Fedora since they use RPM (just using bunch of if-elses here and there). We can just stick with your usual way where it downloads the pre-built binary for debian-based distros but we will build for opensuse and fedora.
I also have to check openSUSE policies for doing these since it builds for various distributions that are not just openSUSE (but also because I wanted to add Crystal to openSUSE Factory).
IIRC we started with the 
