[build] Make raylib available in package managers

Question

[build] Make raylib available in package managers

raysan5 opened this issue 6 years ago · 43 comments

raysan5 commented 6 years ago

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

Currently supported package managers:

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

Answer 1 · 2018-07-30T14:10:55.000Z

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

Answer 2 · 2018-07-30T14:14:32.000Z

@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.

Answer 3 · 2018-07-30T14:23:09.000Z

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

Answer 4 · 2018-07-31T05:09:45.000Z

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

Answer 5 · 2018-07-31T10:01:02.000Z

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?

Answer 6 · 2018-08-19T06:53:05.000Z

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 #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.)

Answer 7 · 2018-08-19T16:02:06.000Z

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?

Answer 8 · 2018-08-19T18:57:43.000Z

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. 😄

Answer 9 · 2018-08-25T16:35:40.000Z

releases directory removed in commit d6241d1

Makefile outputs to RAYLIB_RELEASE_PATH automatically on building.

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

Answer 10 · 2018-08-25T17:10:25.000Z

No worries at all. 😄

Answer 11 · 2018-09-14T06:22:06.000Z

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).

Answer 12 · 2019-04-05T02:33:28.000Z

One more: microsoft/vcpkg#5946

Answer 13 · 2019-04-05T09:50:40.000Z

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

Answer 14 · 2019-06-02T19:51:42.000Z

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

Answer 15 · 2019-06-02T20:01:21.000Z

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

Answer 16 · 2019-06-02T20:07:21.000Z

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

Answer 17 · 2019-06-02T22:56:52.000Z

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?

Answer 18 · 2019-06-03T09:07:34.000Z

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:

Answer 19 · 2019-06-04T14:22:37.000Z

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.

Answer 20 · 2019-06-04T15:11:42.000Z

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?

Answer 21 · 2019-06-04T15:17:32.000Z

@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.

Answer 22 · 2019-06-04T21:12:11.000Z

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)

Answer 23 · 2019-06-04T21:15:17.000Z

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

Answer 24 · 2019-06-05T06:55:16.000Z

@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?

Answer 25 · 2019-06-06T09:28:45.000Z

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

Answer 26 · 2019-07-02T01:39:18.000Z

AppGet for Windows is missing from the list.

Answer 27 · 2019-10-08T14:26:01.000Z

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

Answer 28 · 2019-10-08T15:34:15.000Z

@elitepleb oh! looks nice! :D

Answer 29 · 2019-10-23T14:40:55.000Z

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

Answer 30 · 2019-12-04T10:11:07.000Z

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

Answer 31 · 2021-09-20T10:05:55.000Z

is a Raylib package available on Debian?

Answer 32 · 2021-09-20T10:43:09.000Z

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

Answer 33 · 2023-03-04T01:54:47.000Z

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.

Answer 34 · 2023-03-04T12:59:57.000Z

@ranguli Sure! Feel free to add it!

Answer 35 · 2023-10-19T09:52:41.000Z

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!

Answer 36 · 2023-10-19T10:18:27.000Z

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.

Answer 37 · 2024-01-13T14:29:33.000Z

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.

Answer 38 · 2024-01-13T14:34:10.000Z

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

Where people can see all repos.

Answer 39 · 2024-01-13T15:02:51.000Z

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

Answer 40 · 2024-01-13T15:26:35.000Z

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 :)

Answer 41 · 2024-01-13T23:35:31.000Z

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.

Answer 42 · 2024-01-14T07:16:50.000Z

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

Answer 43 · 2024-01-15T01:31:31.000Z

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