Retropie-setup: retropie as package instead of image?

[nschloe]

When I downloaded another several Gigs worth of RetroPie, I wondered whether it shouldn't actually be possible to distribute RetroPie as an ordinary Debian package instead of a full-fledged SD image. What exactly keeps us from doing this?

[joolswills]

You can just install retropie-setup and install/update from the script though - there is a lot of work involved with packaging etc. All the binaries are available, so an install via the script is relatively quick and easy. The SD image is created for those that want a ready to run system without having to install retropie on top of raspbian themselves.

[joolswills]

The pre-made RetroPie image is under 700mb compressed, not several gigs btw.

[nschloe]

You're right: The major annoyance isn't so much the download, but rather the fact that you have to wipe your entire system to upgrade with an SD image. (Judging from the website and the wiki, this seems to be recommended method.)

All the binaries are available, so an install via the script is relatively quick and easy.

Interesting! Shouldn't it be possible then to create DEB-packages from this, too? The idea I have is that RetroPie updates are coming in via

$ sudo apt-get dist-upgrade

just like all other packages, too.

[taalas]

You don't need to re-flash the whole image to upgrade your RetroPie installation. It is sufficient to just upgrade the setup script (using the update set script option), restart the script and perform a binary installation (the first option in the script). This will update all standard modules to the latest binary versions. I do agree though that the documentation could be a little clearer on this option, we are in the progress of updating it.

[nschloe]

Everywhere RetroPie is offered for download, I see images. What exactly comprises 3.0_beta then? Is it really just the script that does everything? Can I just install a raspbian, clone the script, and then have an up-to-date system for as long as I update the binaries? (You notice that I don't see clearly here.)

[taalas]

Effectively yes, you can install a Raspbian, clone the script and then use binary installs to install a RetroPie installation and update the base modules by choosing the binary installation again. The SD image is a convenience option for people who prefer a pre-installed ready-to-go environment, but it basically is just a snapshot of a Raspbian with an installed RetroPie base installation.

[nschloe]

Hm, this sounds like it's be easy enough to set up installation instructions along the lines of

• fetch and install a Raspbian image
• add RetroPie repository to sources list
• install/update as usual (apt-get update && apt-get dist-upgrade)

[taalas]

I agree that it would be easy to communicate this way of updating a local installation, although it adds a currently unnecessary overhead of maintaining an update repository when the current way of

• start RetroPie setup script (or clone when doing the first installation)
• update setup script from menu
• restart RetroPie setup script
• perform binary installation

works perfectly fine.

[nschloe]

@taalas Agreed. Like you said earlier, what should probably be done is to properly document this way of installing and maintaining a RetroPie installation.

Anyhow, I'll possibly look into creating a repo for this at some point. :)

[jedahan]

@nschloe FWIW, I would appreciate a deb / repo with a deb as well. Then I could make a docker script for building the image easily :)

[joolswills]

We wouldn't want to have a single deb for everything - as it wouldn't be able to simply update a single component. We discussed the idea of using debs before, but it is a lot of work to properly package them (so configuration would be handled as part of it etc).

The current method of updating is simple, and I'd rather spend time on improvements to the configurations / and fixes / new emulators than more work on the way the system is managed - Note there has already been a ton of work to make retropie quite modular, and to split out everything (we have per emulator archives now, rather than a single archive for everything).

[nschloe]

We wouldn't want to have a single deb for everything

That's right, it'd certainly be sane package all the bits and pieces into separate packages. Some of those might already be there (e.g., ZNES), but I haven't really checked. For certain, this would require some work. Some will say that given the target platform (Raspbian), it'd be worth the while.

The current method of updating is simple,

Hm, well, it's not as simple as it could be. After all, RetroPie rolls its own dependency management and build system right now, which is no doubt a great thing to have, but it dismisses the good things one would get from leveraging the existing Debian infrastructure.

Anyhow, my intention is not to kick the project into another direction build-system wise. Maybe, if I have time during the summer, I'll code a little bit around Debian packages, and I'll let you know if this has some success or not.

[joolswills]

proper debian packaging takes a long time. There are also lots of things that would need to be changed in the way configuration steps are performed (and the requisites in the main script).

We do have some basic dependency management, but we would still need to manage that for the debian packages too - so it wouldn't mean less work. I have maintained some debian packages in the past as part of another project, and it certainly took up a lot of time.

I would also be tempted if looking into packaging to move towards something that isn't debian specific.