[Split] Distro vs oolite.org binaries

[herodotus]

Split from PNG Warnings topic in Expansion Pack

@herodotus
Have you tried the oolite.org package? It is actually the recommended package to use.

Does it actually work an Arch? I was under the impression that only the pacman packaged version worked on Arch. Also I don't really like installing software outside of the package manager unless absolutely necessary because it's a slippery slope to dependency hell.

[Getafix]

The Oolite package, brings its own library ecosystem, contained, in the Oolite installation folder. It doesn't mess with your system's libraries.
The Oolite libraries are only seen by Oolite itself. They are not in the system's libraries paths and no other application can see them.

If you choose to perform a home folder installation, nothing is installed outside your home folder.

Considering that you already have an installation in place, I suggest you try the following,
1. Backup your OXPs, OXZs, savegames, snapshots and logs
2. Uninstall the distro released Oolite installation
3. Install the oolite.org package (see this post for a how-to; it is meant to be straightforward)
4. Restore your personal files as follows

• OXPs in ~/GNUstep/Applications/Oolite/AddOns/
• OXZs in ~/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/
• savegames in ~/oolite-saves/
• snapshots in ~/oolite-saves/snapshots/
• logs in ~/.Oolite/Logs

Clarifications:

• The symbol ~ indicates your home folder e.g. /home/herodotus/
• You may need to manually create the folder ~/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/
  This is automatically created by the Expansion Pack Manager, when the first OXZ is downloaded. However, in your case, you are manually restoring, so you should manually create it.

That's all... I think...


EDIT:
I forgot to answer the main question.
Yes, it works on Arch, as well as on a multitude of Linux distros.

It has been actually tested on

• Slax 7
• CentOS 7
• Fedora 25.1.2
• LinuxMint 18
• Mageia 5.1
• Manjaro 16.10.3
• openSUSE Leap 42.1
• Ubuntu 16.04

[another_commander]

Should we sticky the information in this last post by Getafix? The subject of problematic distro installations of the game that almost invariably gets resolved by simply installing the oolite.org binaries seems to be coming up at an alarming rate lately.

[Cody]

Should we sticky the information in this last post by Getafix? The subject of problematic distro installations of the game that almost invariably gets resolved by simply installing the oolite.org binaries seems to be coming up at an alarming rate lately.

I've often wondered how many people install Oolite from a distro, find it's broken, uninstall it, and walk away. Sticky it on every distro's website!

[Getafix]

I can add a new post in the Linux forum and make it sticky.

However, Linux users, are instructed that if they want to be safe and keep their peace of mind, they should avoid installing third party software and only "play" within the safety and simplicity boundaries of distro repo applications; something like Nemo and the safety of the Great Barrier Reef.

To tell you the truth, I would not object to that mentality. Third party apps, tend to spread their files in a multitude of folders with no obvious (for the user) rule.
Furthermore, uninstalling these apps, if you manage to find a way to uninstall them (!!!), usually leave useless files and folders.

Consider, that in Oolite for Linux, we only managed to tidy up things, with the new self-extracting installer, introduced with Oolite for Linux 1.75.2-beta release back in 2011!
Even in this case, we could not (for compatibility with Oolite distro repo releases) avoid having to create ~/.Oolite/ (for Logs and AddOns) and ~/oolite-saves/ (for savegames and snapshots), in the user's homefolder and not in the Oolite installation folder.

[herodotus]

Ok, this all sounds good, but then it does raise the question: why can't the "official" package for Oolite on Arch use the bundled libraries rather than formal deps? Is this a "religious" thing whereby packages with bundled libraries aren't allowed in the arch repos? If so, would it be worth looking at making an AUR version instead that does things this way?

[Getafix]

Can someone do a split, please, putting this under Linux forum? ( @another_commander)

@herodotus
This is a question for the Arch Linux forum.
However, I think that this depends to each distro's package management system as well as its release model.
It's more a matter of trying to model a modus operandi to be able to control things than being "religious".

Furthermore, initiatives such as Snap, Flatpack, etc., come into the picture, in an attempt to address the case in a unified way, where a third-party software provider, wants to run an application in its own sandbox ecosystem.

So far none of these attempts have managed to be the "standard" way of doing things, when you want to run your application in your own sandbox.
Considering the openness of the Linux world and the 307 currently active Linux distros, it will be difficult for an initiative to dominate them all.

[Getafix]

A split starting at this post would be good I think.

@herodotus
Have you tried the oolite.org package? It is actually the recommended package to use.

Does it actually work an Arch? I was under the impression that only the pacman packaged version worked on Arch. Also I don't really like installing software outside of the package manager unless absolutely necessary because it's a slippery slope to dependency hell.

[Stormrider]

Also I don't really like installing software outside of the package manager unless absolutely necessary because it's a slippery slope to dependency hell.

I found this to be much to limiting for my taste. I've been trying to compile my own software if I can, but if I can't I try to find a tar download that is self-contained like Oolite. This might take up more space but its ok for me for the few programs I do it with.
I can't imagine why the linux developers believe everything installed on a system should be restricted to a single set of dependencies.

Is this a "religious" thing whereby packages with bundled libraries aren't allowed in the arch repos?

You might look into flatpaks, snaps, or appimages for Arch, these are different package management systems that will provide packages with bundled libraries. Flatpaks are now available from Mint's software manager which might offer a good alternative, but I am not very impressed with the funky sandbox thing.

Sticky it on every distro's website!

Try to convince distros to admit the software in their package management systems might be less reliable than the ones provided by the developers of the software themselves? Ya,good luck with that.
There seems to be a robotic mindset that the only software that can be considered trustworthy or stable has to come from the repository, where its been compiled with a different runtime environment than it was developed with by someone who may not even have anything to do with the development of the software at all.

Third party apps, tend to spread their files in a multitude of folders with no obvious (for the user) rule.

My experience is actually the opposite, Wings3D -one folder in my home folder when I get it from a tar, I have a few others like that as well. I never know where apt-get might decide to put something and it always spreads the files into a multitude of folders with no rules that are apparent to me. I have noticed things migrate around some as well so the rules seem to change.
Thinking of flatpaks what are your thoughts about bundling Oolite as a flatpak or similar package?

[another_commander]

Also I don't really like installing software outside of the package manager unless absolutely necessary because it's a slippery slope to dependency hell.

In the case of Oolite, it looks like dependency hell is exactly whqt most people installing from the distro repositories end up dealing with.

[Getafix]

...My experience is actually the opposite,...

I agree, that not all the 3rd party delivered applications do that. But even if there are a few bad examples, then, the user rushes back to the repo and never go out again!

Thinking of flatpaks what are your thoughts about bundling Oolite as a flatpak or similar package?

I'm more than eager to see it and test it, but alas, I don't have the time to checkout the packaging suggestions.

I'm looking for a volunteer
to take over the ownership of this initiative,
investigate the options that seem viable for the years to come,
discuss these options' characteristics internally, in order to find one or more packaging methods candidates,
start preparing some packages to first test internally and then experimentally deploy to the community for anyone willing to try it.
After a period of testing, we could officially put it in our official releases.

The oolite.org packages will remain as long as they continue to demonstrate the vast portability and stability characteristics they show for the last 6 years.

[Commander_X]

<tosses his 0.02 currency contribution/>
Big Brother companies usually solve this issue by offering their Linux stuff in a three way split: for yummers (.rpm), apt-getters (.deb), and the rest of the world (Linux, they call it - it's usually an Oolite like type of installation, one form or another of shar -- SHell ARchives).

RE: the "religious" part -- the packaging in Linux world can be seen as a canon, usually defining the type of distro you're working with, e.g. from Getafix's list, I can easily spot .deb, .rpm and .txz based distros (this last being for Slax 7, which was based on Slackware; Slax 9 became Ubuntu based, thus .deb).

[herodotus]

So, just tossing a few more cents into the pile:

Who maintains the "official" arch package for oolite? Would they definitely be opposed to the idea of having the package simple wrap the existing script provided on oolite.org? That would allow the app to work as intended by the devs even when installed from the repo. I for one only found out about oolite by browsing the arch repo for games, and I'm sure a lot of other people are going to default to that path.

Re: dependency hell, I'd respectfully disagree with those thinking that self-contained packages are the answer. It works ok for a time when you have a small number of dependencies that you understand fully. But it opens you up to a whole load of issues in the longer term - for example shared configuration for components becomes challenging and obviously there's the bloat. As someone who used to write Java web apps I can tell you that bundling all your dependencies definitely does not solve all your problems! When you spend days tracking down weird bugs caused by multiple versions of the same class existing in memory at the same time, having each app bundle its deps looks a lot less attractive.

The other thing is that in the end it just defers problems. If oolite continues to be developed actively, some day, there will be a compelling argument for bumping one of the dependencies. Maybe because it would improve the software, or maybe because libXYZ.1.0 depends itself on a deprecated OS feature that has now finally been removed. By that point it may have its own updated dependencies, which cause their own problems (obvious if you're lucky, latent and subtle if you're not) and suddenly you have a horribly gnarled mess that needs to be fixed all in one go, and no one wants to tackle it - so it never happens. I've seen a lot of FLOSS projects slowly die that way Personally, I've found that the small, recurrent pain involved in keeping dependencies tolerably up-to-date as you go is far outweighed by the crushing dread of facing down 5 years' worth of updates in one go. But I guess that's a personal preference: you pays your money^H^H^H^H^Htime and takes your choice!

For the avoidance of doubt, I'm not trying to persuade anyone to change the way Oolite is currently managed in this regard. You've got a system that works for you and that's great. I'd just like to throw in my defence of the general concept of the mainstream package management approach for the sake of balancing the discussion

[Commander_X]

[disclaimer: I am a very long time Slackware dabbler]

Who maintains the "official" arch package for oolite?

That should be someone in the arch packaging team.

For the avoidance of doubt, I'm not trying to persuade anyone to change the way Oolite is currently managed in this regard. [...] I'd just like to throw in my defence of the general concept of the mainstream package management approach for the sake of balancing the discussion

There are many very popular packages "out there" distributed by their developers exactly as Oolite is (I can quickly come with open source Firefox, Blender, or the commercial VirtualBox, or NVidia's drivers for Linux). For most of these you'll also find distribution specific packages (usually not provided by the developers, but maintained by the distribution people).

I think the main two reasons a program will make into a "classical package" for a specific distribution are popularity and development cycle matching. While the first reason it's quite obvious, the second one is the drawback a project like Oolite is facing (and which can be called the "dependency hell"). Without getting into too much detail, a small team of developers and a long release cycle make it difficult to keep pace with all the new stuff.

One of the bottom lines would be that Oolite is doing quite well with its binary distribution (which is self contained, and rather portable across the large number of Linux flavors).

The other bottom line is that repackaging Oolite for a specific distribution should be made with more caution by the maintainers (and here -- I'm not pointing fingers -- I think the token should be passed to the distribution people). If they have any doubt of how the things should be handled (either compile wise or just re-bundle of the Oolite official Linux distro), that is what this forum should be for.

[Stormrider]

I'm looking for a volunteer

Wait a minute. Isn't this the part where everybody else in the line steps back and I look like the one who...
I wish I had the time as well, but with some neglected oxzs that need updating, a humbucker kit, and a vintage Gibson amp I've got stripped down to the circuit board I really don't think its realistic. I'm not sure I am that qualified anyway, I might be able to compile oolite for my own use but analyzing different package delivery systems to help decide which is the best to use to port oolite to multiple linux distros is certainly beyond the scope of my meager abilities.

Re: dependency hell, I'd respectfully disagree with those thinking that self-contained packages are the answer.

What is the answer then? I agree that it creates bloat and although I've never had issues with multiple versions existing in memory at the same time I certainly wouldn't deny its possible, but what other way is there?
As far as I can tell its the only way to allow developers of independent software the freedom to create the best software they can while allowing users the freedom to use that software with any OS (not just unix based).
I don't know much about Arch really but I am certain that the maintainers for debian or ubuntu would even consider packaging the existing script provided on oolite.org, for one thing they would be too worried about bugs that might be caused by having multiple versions of the same class existing in memory at the same time, although as I said I never had any problems running oolite or blender or pale moon or any of the other software I run this way.

I'd just like to throw in my defence of the general concept of the mainstream package management approach for the sake of balancing the discussion

I feel its a horribly repressive system that curses the developer to a basic set of restricted deps that cannot be customized or improved without the approval of some obscure community that accepts no input whatsoever from the common user or independent developers.

The real problem is not with independent developers who often struggle to find the time to do any actual development. Its the ones who constantly change the structure of these dependencies with complete disregard for any backwards or forward comparability. Cross platform compatibility is non existent even within the linux community itself, if the oolite devs wanted to create a package that would run specifically on Arch the would have to maintain a completely different package to run on Redhat and possibly another for Debian, and then there is windows and OSX.
How much extra work is it to maintain four or five different packages?
You are completely welcome to repackage oolite with all the latest deps on Arch and maintain it to keep it all up to date with Arch's rolling release cycle but I have no wish to curse the devs to such a miserable task. That would surely kill oolite.

Sorry this came off as a bit a a rant, nothing personal or anything, and really you shouldn't take me too seriously, I am quite aware of how little I really know.