retrorig-setup Debian pkg restructuring

[mdeguzis]

@beaumanvienna , what is the reason we copy all the directories down to /usr/lib? Is it just a spot you picked? My idea for restructuring things, is to make a clone of the current retrorig-setup.sh script file, ammend the scripts and modules to install the "core" files (no gamepad, or xbox360 as default). I would remove anything that requires interaction. Mainly this would/should install all base software and update the kernel (if necessary, as this may be patched for ps3 wired controllers, I have to test).

I'll try to come up with something in the coming week to show you. The debian package should not be copying anything into /usr/lib, unless I am misunderstanding that. I will copy an archive into /home/user/RetroRig, extract it, and run a the core install, requiring no user imput. At the end, the user will be notified that in order to setup the controller and other options to run retrorig-setup.sh to reconfigure.

Ideas?

$(CURDIR)/debian/tmp/usr/lib/RetroRig

[beaumanvienna]

I would remove anything that requires interaction.

I would keep the setup as it is right now.

I will copy an archive into /home/user/RetroRig, extract it, and run a the core install, requiring no user input. At the end, the user will be notified that in order to setup the controller and other options to run retrorig-setup.sh to reconfigure.

A debian package always extracts to a system folder. That doesn't require user input. It equals cloning from github. I would recommend to keep both methods, a) clone it from github in a local dir and run it as we do now or b) get it via apt-get into a system location . The old way sudo ./retrorig-setup.sh remains for the git way. In the latter case, a user who wants to install
retrorig says sudo retrorig-setup. Our script will detect to be called this way. It will create a folder RetroRig in the current directory of executing the script, and change into it. It will adopt the path to the script modules and template files to the system location. It will omit some file copying for files that had been installed by the Debian package already. The local RetroRig folder doesn't contain any scripts, or pre-installation files anymore (XBMC-cfg, emu-cfg, etc.), just ROMs, BIOS and Saves. I don't know about Artwork, if a user would need that, or if all users on a system could share it. Internal files like our packaging stuff will not be installed. This way we get

• the standard method of installing programs for Debian based systems
• a fast download from the PPA
• separation of internal scripts, template files and helper files and actual settings/configuration files needed to run RetroRig

copy how?

[mdeguzis]

A debian package always extracts to a system folder.

I meant more along the lines of running the 1) option in the script to get the base packages installed via the debian package so that all a user has to do is configure the controller by heading into the setup. What we have now is fine though since there is a lot going on with changes.

The local RetroRig folder doesn't contain any scripts, or pre-installation files anymore (XBMC-cfg, emu-cfg, etc.), just ROMs, BIOS and Saves.

You mean with the PPA retrorig-setup Debian package right? The rest of our scripts and such would reside in the /usr/lib/ folder you were talking about in the other thread. I think I get where you're going with this. The git clone should just remain that, and those installing from the PPA get things called from a proper place. I can see where you meant moving rather than copying in the Debian rules file.

[beaumanvienna]

I meant more along the lines of running the 1) option in the script to get the base packages installed via the debian package so that all a user has to do is configure the controller by heading into the setup. What we have now is fine though since there is a lot going on with changes.

Ah, now I get it. Over the time we can add more and more install functions to the Debian package post-installs, until eventually the config run is just configuring the controller. The idea is good.

I thought a little about how we can move to systems other then Debian-based. We should move the system identification to the very beginning of function rrs_add_standard_repos(). For all Debian-based systems we should set a flag DebianDerivate=true, and add the PPA's according to this boolean variable.

I can see where you meant moving rather than copying in the Debian rules file.

I think I already stumbled over this with service rescan, probably we need to test in the script if the file exists before copying.

[mdeguzis]

I thought a little about how we can move to systems other then Debian-based. We should move the system identification to the very beginning of function rrs_add_standard_repos

Ok, I'll take a look at this tonight. Probably concoct something out of uname or a similar program.

On another note, we no longer need the manual kernel upgrade. This was fixed not too long ago, but I can confirm it works on the latest 3.13.0-37 of Ubuntu 14.04 LTS. I will disable this for now. If not already, I'll ensure the install updates the system appropriately.

[beaumanvienna]

Ok, I'll take a look at this tonight. Probably concoct something out of uname or a similar program.

I did the detection with lsb-release. This can be used to decide if we use apt-get or pacman etc.. Maybe even to source a completely different emulators.shinc.

[mdeguzis]

Great job :) This skeleton structure can then be used to extend it to Debian derivatives etc, and other platforms when ready. I see you noted 14.10. Should we have a "catch all" case line for the base 14.04 Trusty / Minty, or anything that works "out of the box" ?

[beaumanvienna]

Yes, a default case would be good. In this test we could test for the availability of apt-get or pacman, to get a half decent estimate on what system we run.

[beaumanvienna]

Is there anything else we need to do in here? Maybe a man page?

[mdeguzis]

I have a very* basic manpage here that I started under the supplemental folder. It needs a lot* of work to explain a ton of things. I didn't look at your build script update in your PR yet, but i'll have to manually check some things out. Since retrorig-setup is our script, I did cut the 0: prefix, since we don't need it (e.g. retrorig-setup 0.9.5.4).

Also, at some point this week, I really* need to document how each of our files (the .desktop file, start-xbmc.sh and the like, and how they all interface") in the Advanced Configuration wiki page. This will help keep me especially straight on how all our different files interfaces (loading modules during install etc.)

[beaumanvienna]

I didn't look at your build script update in your PR yet, but i'll have to manually check some things out. Since retrorig-setup is our script, I did cut the 0: prefix, since we don't need it (e.g. retrorig-setup 0.9.5.4).

We can delete the prefix, no prob. I improved the script to make it more convenient to switch between our individual settings (official releases for you and testing releases for me). I noticed you have a different version in your PPA then it was stated in the script, so we probably have to merge it. Just remember that I can merge these kinds of conflicts as well. Just commit your changes, I can then fetch the upstream again , which will force me to merge it. Normally the person for issuing the PR should also be responsible for merging.

Also, at some point this week, I really* need to document how each of our files (the .desktop file, start-xbmc.sh and the like, and how they all interface") in the Advanced Configuration wiki page. This will help keep me especially straight on how all our different files interfaces (loading modules during install etc.)

Excellent!