Option to build stable packages from source?

[vbs]

Currently in retropie-setup you can either install packages from binary (not on x86) or build them from source. The source builds happens for most packages from their current master branch. So when building a package from source you might just hit a bad moment with an unstable master. When building whole RetroPie with, dunno, more than 30 (?) packages then I am afraid it is not unlikely that you will hit a bad one here or there.

Usually this is fine when you can choose to install either the stable binaries or compile bleeding edge from source. But on systems where binary installs are not available you are forced to use everything from current masters (risky).

So I would like to propose an option in retropie-setup that let's you choose when building a package from source if you want to use current master or if you want to build the same revision that was used to build the stable binaries. So the first question (buzz?) would be if this would be a feature you would support or if it is something you don't see appropriate for RetroPie.

Tbh I have no good idea yet how to do this in the end. With just git in mind it would be fairly easy to store a list somewhere with commit hashes for all packages that should be used when building stable from source. It gets more tricky when considering that each package could obtain the sources in whatever way it wants (svn, hg, ftp, whatever...).
I could not find information so far about which sources are used to build the (RPi) binary packages. Ideally the same piece of information (probably it is stored somewhere) would be available to retropie_setup to build stable packages from source also.

So what do you guys think?

[BuZz]

Most of the packages are stable - there are just a few that sometimes go through heavy development (eg retroarch).

I have considered adding support for multiple versions at some point, but it's a a fair amount of work to implement - bear in mind that with things like retroarch, the configure flags changed over time, or with other packages they moved from sdl1 to sdl2 so you would need to maintain separate code blocks for building the various versions.

Which packages are you thinking about where it makes sense to maintain different versions ?

Also when you use the word stable, there is no such thing with the libretro cores, apart from manually maintaining lists of revisions etc. They dont have "releases". They are just continually developed as with RetroPie.

[vbs]

@BuZz said in Option to build stable packages from source?:

Most of the packages are stable - there are just a few that sometimes go through heavy development (eg retroarch).

I have considered adding support for multiple versions at some point, but it's a a fair amount of work to implement - bear in mind that with things like retroarch, things like the configure flags changed over time, or with other packages they moved from sdl1 to sdl2 so you would need to maintain separate code blocks for building the various versions.

Hm yes, true, this is quite evil and kinda spoils the fun :( Those two separate code blocks would be probably the only solution indeed. But quite some work to maintain. Maybe it makes sense to only support "stable from source" for selected packages where it is appropriate (like retroarch).

Which packages are you thinking about where it makes sense to maintain different versions ?

I stumbled upon this subject cause of retroarch primarly (I think once I also had an issue with one other package but can't remember anymore). You are certinaly right about most packages being stable but since retroarch alone seems very dynamic at the moment and also is one (the?) key component of RetroPie it is a bit of a problem I think.

Also when you use the word stable, there is no such thing with the libretro cores, apart from manually maintaining lists of revisions etc. They dont have "releases". They are just continually developed as with RetroPie.

Yes, I meant "stable" in the sense of being the same version as the one that was used to build the RPi packages. Probably the majority of RetroPie users is using the RPi binary packages so I think there are good chances that those can be considered at least mostly stable (otherwise it would pop up quickly).

So, I could offer to make a proposal for optional functions in package scripts so the menu would offer something like "Install stable from source" if those functions are available for a package.

[BuZz]

@vbs more that just the build part. the configure part would be different too in some cases. So you would need a lot of extra logic. That said, I did consider it for retroarch - however, I am hoping that soon it will stabilise. I don't know if I want to maintain the extra code.

It was really just our patch which broke anyway, and things like this would still need to be fixed.

The retropie binaries are nothing special. I rebuild some stuff if there are notable changes. I reuibld retroarch every now and again, I just test that it worked before uploading the binary.

With RetroArch would you choose releases as the "stable point" ? many releases had important fixes come out just after them for example. Current retroarch works fine - I just need to rework our hack a bit for it. You would probably need to maintain a list of revisions. You would also need additional "configure" scripts for each release as options were removed/changed (not the build configure, but the code to set up the ini file etc)

[vbs]

@BuZz said in Option to build stable packages from source?:

@vbs more that just the build part. the configure part would be different too in some cases. So you would need a lot of extra logic. That said, I did consider it for retroarch - however, I am hoping that soon it will stabilise. I don't know if I want to maintain the extra code.

Yes it would affect the whole thing, also the install part might be different.

With RetroArch would you choose releases as the "stable point" ? many releases had important fixes come out just after them for example. Current retroarch works fine - I just need to rework our hack a bit for it. You would probably need to maintain a list of revisions. You would also need additional "configure" scripts for each release as options were removed/changed (not the build configure, but the code to set up the ini file etc)

Ok ok, I see it now that the afford is more than I initially thought and also the gain is less than what I was hoping for. :) So lets better leave it at that for now. Thanks for clearing it up anyway!

[BuZz]

@vbs It's not a bad idea (I have thought a lot about it - especially when I was doing the reorganisation of the retropie-setup menus), I just think it's really only retroarch which would benefit (maybe a couple of others) - so it's whether the work is worth it. I'm pretty certain it will be me who has to maintain this long term too. I'll see how retroarch develops though and reconsider it in the future if it seems required.