[build] Make raylib available in package managers

[raysan5]

This issue is a follow up of #401 . Just moved to a new issue flor clearness.

Currently supported package managers:

• macOS - Homebrew
• Windows - Chocolatey
• Windows - vcpkg
• Linux - openSUSE
• Linux - Arch User Repositories (AUR)
• Linux - Linuxbrew
• Linux - Gentoo
• Linux - Debian
• BSD - FreeBSD

If you are able and willing to help, you're welcome!

[raysan5]

Just noticed that openSUSE (@jubalh) and Arch (@nounoursheureux) are not updated to raylib 2.0, still 1.8.

[jubalh]

@raysan5 thats wrong. openSUSE Tumbleweed is updated to 2.0 on 24th July in the devel project https://build.opensuse.org/package/show/devel:libraries:c_c++/raylib. From then it goes through test rounds and landed on 28 July on Factory project. And from there will be shipped in the next snapshot.

[raysan5]

@jubalh oh, sorry! just look for it on the net and found that version... Thanks for the update! 👍 😄

[define-private-public]

I have experience doing debian packaging; I can offer my assistance for this. Though, I do want you to know that there are MANY different options to do this. Though this library is open source, I'd recommend creating a binary package (as they are a tad simplier to work with).

What's the status though on the CMake stuff? I know I helped with it a while back, but I'm really out of the loop on it. There does exist a command in CMake to generate the debian stuffs: https://cmake.org/cmake/help/v3.0/module/CPackDeb.html

[a3f]

There does exist a command in CMake to generate the debian stuffs

CI is configured to push a binary package (tarball) to the Github releases page whenever a new release is tagged, so we could use that. Anyone interested in trying to get it into the official repositories?

[QuLogic]

There are a couple issues making packaging a bit bothersome:

• The binary tarball is small, but it cannot be used to create a package; everything must be built from source.
• Using the snapshot tarball from GitHub will work but it has a lot of extra pre-built stuff in the release directory that we don't want. It seems like this sort of stuff should be on a separate branch or repo, or just left to the GitHub releases page.
• Would be nice to have a release with CMake: Major cleanup to support find_package(raylib) #608 since it fixes not only CMake issues, but building against the latest glfw release. (It does not cleanly apply directly to 2.0.0.)

[raysan5]

Now that we have CI and automatic release generation, maybe we can avoid release folder?

Probably build system needs to be updated to output to some default system folder?

@QuLogic Is it right if I publish a 2.1-dev release?

[justinclift]

A 2.1 or 2.1-dev release would be good from my PoV. It'd get the extra keyboard keys added today out "into circulation" faster. 😄

[raysan5]

releases directory removed in commit d6241d1

Makefile outputs to RAYLIB_RELEASE_PATH automatically on building.

Need some time for a 2.1-dev release...

[justinclift]

No worries at all. 😄

[carlsmith]

A package for Raspbian would be awesome.

The installation instructions for RaspberryPi in the wiki are broken (I'll open a separate issue soon).

EDIT: The instructions should work fine with the latest version of raylib (it failed on a dep that wasn't actually needed).

[myd7349]

One more: microsoft/vcpkg#5946

[jubalh]

Nice one! Already wanted to do the vcpkg myself :)

[wbrbr]

The Arch Linux package has been moved from the AUR to the official repository ! I am no longer the maintainer.

[raysan5]

@wbrbr oh! nice! is someone going to update it to latest release?

[wbrbr]

Yes the new maintainer should do it soon since it has been flagged as out of date. I can't give you more details because I don't know them haha

[a3f]

I am wondering if we should start incrementing SOVERSION every 2.x release to prevent applications dynamically linked against one raylib version from having a later, backwards incompatible, raylib loaded. Thoughts?

[jubalh]

I am wondering if we should start incrementing SOVERSION every 2.x release to prevent applications dynamically linked against one raylib version from having a later, backwards incompatible, raylib loaded. Thoughts?

I am saying this since years (on various issues here and on the chat) :-)

See:

• [build] Use library versioning #293
• Add library versioning #299
• Review on Add library versioning to Make/CMake build systems #417
• [build] Make raylib available in package managers #401 (comment)
• raylib 2.5 roadmap #744 (comment)

[a3f]

Its also important to increase the major version number of the library version upon every ABI incompatible release (no need to increase general raylib major version just shared object major version number).

@jubalh, I've missed this comment of yours. I just noticed the discussion around breakage on minor versions. I am in favor of this. I would suggest that we start incrementing SOVERSION directly after every software release with the normal library versioning scheme unaffected.

[raysan5]

I was thinking in a way to increment API version consistently with library version.

Considering API and ABI are very prone to changes, maybe we can just use RAYLIB_API_VERSION = 250 and increase that number aligned with 2.5.0. What do you think?

[a3f]

@raysan5 incrementing API version directly after a release would allow the git version to be installed alongside the released version and binaries linked against an old version or explicitly requesting the released version would continue to work.

If we increment before the release, this wouldn't work.

[a3f]

What we could do is set to 251 now, 260 on release and 261 directly after... ? (granted that 2.6.0 is the next version)

[raysan5]

How often should we increase the revision number? I mean, 252-253-254...

[a3f]

@raysan5 What we absolutely want is for every release to have a different API version. A different API version for the git trunk is nice to have because issue reporters are often told to try the newest git snapshot, so we shouldn't accidentally break their already linked applications if they install from git.

Breakage will still happen, if you install an unreleased git snapshot, dynamically link, and come back later to install a newer version from git. But if you do that, we'll assume you're experienced enough to expect breakage and to deal with it.

To sum up:

• Just before tagging the release:
  • set software version to new version
  • set API version to software version / 100
• Directly after tagging the release:
  • increment API version by one

Both commits can be done together. Thoughts?

[raysan5]

@a3f ok, I understand, it looks ok this way.

[VelocityIsntSpeed]

AppGet for Windows is missing from the list.

[elitepleb]

any fans of alternate build systems here?
I'm looking for someone to finish this xmake package

[raysan5]

@elitepleb oh! looks nice! :D

[sudopluto]

Might look at some of the opensuse packaging to make a fedora copr repo, no promises though.

[raysan5]

raylib is already available in some package managers. I think this issue is not the best way to track those packages... Closing the issue.

[Vantadaga]

is a Raylib package available on Debian?

[jubalh]

is a Raylib package available on Debian?

No it is not.
Here you can see where it is available: https://repology.org/project/raylib/versions

[ranguli]

I know this issues is closed, but it would be really awesome if a Debian package could be created, given that apt is one the most common and widely used package managers.

[raysan5]

@ranguli Sure! Feel free to add it!

[Star4Fun]

Hello there,

I've developed an ebuild for Portage in Gentoo, and I'm considering making it available to the community. While it's not public yet, I'm keen to gauge interest. If there's interest, I'll be happy to maintain it and potentially work on getting it included in the official upstream repository.

Please let me know if you'd be interested in this ebuild, and if you have any advice on the process of contributing to the official upstream, I'd greatly appreciate your guidance.

Thank you for your time and consideration!

[jubalh]

Please let me know if you'd be interested in this ebuild

You don't need to ask it raylib upstream. Just push it there.

if you have any advice on the process of contributing to the official upstream, I'd greatly appreciate your guidance

It's pretty well documented:
https://wiki.gentoo.org/wiki/Proxied_Maintainer_FAQ
https://wiki.gentoo.org/wiki/GitHub_Pull_Requests

Let me know if you need more help.

[abreathingcorpse]

Would it be a good idea to link the the Arch official repo instead?
Current link to the AUR does not exist. I can see how this might create an issue here and there.

[jubalh]

In the readme we have a repology badge that links to:
https://repology.org/project/raylib/versions

Where people can see all repos.

[raysan5]

@jubalh That badge is actually amazing! It would be nice if more packages were updated to 5.0.

[jubalh]

Yes, FreeBSD and Guix seem out of date for example
But some of the outdated ones are also older/released distros, like openSUSE Leap 15.1 or nixpkgs stable 21.11. So those are normal :)

[abreathingcorpse]

In the readme we have a repology badge that links to: https://repology.org/project/raylib/versions

Where people can see all repos.

I'm not sure how to get to that link from the README. All I found was this thread. But, if the information is there and I'm just too dumb to find it, that's ok.

[jubalh]

I'm not sure how to get to that link from the README

You go to the README. You look at the badges on top. You click on in repositories

[abreathingcorpse]

Got it. Well, if it won't cause any trouble. then it should be fine. Sorry for the inconveniences.