Celestia Origin for Linux & Mac OS X

[Art Blos]

Dear community. I already repeatedly get questions related to the work of "Celestia Origin" in the Linux family systems.

It is known for certain that with the help of Wine, the collection starts up without problems, but not everyone is happy with this approach.

There are two obstacles to organizing a native installation:
1) The latest official version of Celestia for Linux 1.5.1, in which there are no important software functions for Origin.
2) Our entire team works on Windows.

Although I am not a Linux fan, there are many such people among Celestia users. Therefore, our project will need your help.

What is necessary?
1) I was informed about the existence of an unofficial distribution. It is necessary to test its work.
https://www.archlinux.org/packages/extra/x86_64/celestia/

2) Someone should write an analogue of the file Install.bat - Install.sh.


Now about MacOS.

In it case, there is an official version 1.6.1. But I absolutely do not know whether Origin can be installed on it. Surely there will need its own analogue Install.bat.
If possible, please create such a file.


Thanks in advance to everyone who responds.

[pirogronian]

I always usedCelestia on (Arch) Linux and never see other version than 1.6.1. I was very surprised seeing 1.5 as last official build for Linux.

The second surprise was to see bat file in Celestia Origin distribution. Up to now I dont understand why CO dont work as any other addon and be therefore fully OS agnostic. I know CO is thought to be upgrade, not addon, but I dont see technical reason for such an approach.

[Art Blos]

I always usedCelestia on (Arch) Linux and never see other version than 1.6.1. I was very surprised seeing 1.5 as last official build for Linux.

For me surprise is opposite. So need to upload version 1.6.1 to the official website. This will solve many problems.

The second surprise was to see bat file in Celestia Origin distribution. Up to now I dont understand why CO dont work as any other addon and be therefore fully OS agnostic. I know CO is thought to be upgrade, not addon, but I dont see technical reason fuch such a approach.

Because:
* The location of the same files is different if you compare the clean version with Origin.
* The standard for naming asteroid model files is different. In the clean version without numbers, but we have numbers.
* Formats is different. CMOD instead 3DS.
* I am generally silent about textures, now there are huge differences.

Therefore, a script is used that removes all the differences and duplicates of files.

Can you post a distribution kit ready for use with the version 1.6.1 for Linux (*.package)? And can you help us with Install.sh?

[pirogronian]

* The location of the same files is different if you compare the clean version with Origin.
* The standard for naming asteroid model files is different. In the clean version without numbers, but we have numbers.
* Formats is different. CMOD instead 3DS.
* I am generally silent about textures, now there are huge differences.

Can't it be altered via REPLACE or MODIFY disposition in coresponding .ssc, .stc or .dsc files?

Can you post a distribution kit ready for use with the version 1.6.1 for Linux (*.package)?

I'm not sure what You mean. I don't know .package files, especially in Arch Linux. In fact, there is no universal package format for Linux. I know that @onetwothree maintains debian packages.

And can you help us with Install.sh?

Only if You convince me scripts are really necessary (see above)

[Art Blos]

Can't it be altered via REPLACE or MODIFY disposition in coresponding .ssc, .stc or .dsc files?

Why duplicate the objects code? I am not at all in favor of using the "Modify" and "Replace" functions where I can get by without it.
In any case, these functions do not solve all the problems. Unused files in the program should not remain, how "dead weight".

I'm not sure what You mean. I don't know .package files, especially in Arch Linux. In fact, there is no universal package format for Linux. I know that @onetwothree maintains debian packages.

It is in this format that version 1.5.1 is published on the official website. You can check.

Only if You convince me scripts are really necessary (see above)

Strange approach. If I ask for help, then I’m sure that this is necessary. If you do not want to help, just say. This is better than if you promise, and then do not keep the promise (with a similar request, such a case already happened).

[onetwothree]

Art Blos, there is no "official GNU/Linux builds", that autopackage file referenced on the site is just for quick evaluation, and I doubt that it will work because of the way autopackage files are created. The usual way for GNU/Linux or *BSD users to get an application is to install it from their OS' repository or build it themselves.

Currently with assistance of munix9 we provide regular builds for Debian10, Ubuntu 18.04 and 2 flavours of openSUSE. When intermediate release 1.6.2 is out we'll provide them for it too. But currently it's okay to target 1.6.1.

[Art Blos]

there is no "official GNU/Linux builds", that autopackage file referenced on the site is just for quick evaluation, and I doubt that it will work because of the way autopackage files are created. The usual way for GNU/Linux or *BSD users to get an application is to install it from their OS' repository or build it themselves.

I practically do not understand specialty of Linux, for me it is a "dark forest".

Currently with assistance of munix9 we provide regular builds for Debian10, Ubuntu 18.04 and 2 flavours of openSUSE. When intermediate release 1.6.2 is out we'll provide them for it too. But currently it's okay to target 1.6.1.

So it is necessary to maximize the convenience of Linux users to access exactly version 1.6.1. Provide some ready-made builds (I think not all users can compile them themselves). I will turn to Alexell on this issue.
And version 1.5.1 must be deleted from site.

[pirogronian]

It is in this format that version 1.5.1 is published on the official website. You can check.

Indeed. But it's some strange old format. I'll start to experimenting with Arch Linux format, and ask page admin to post packages mainained by onetwothree.

Why duplicate objects code?

Because otherwise You have to mess with existing data, which, at least on most Linux distros, will conflicts with package information. And, of course, it force You to call for help in order to support various OSs.

I am not at all in favor of using the "Modify" and "Replace" functions where I can get by without it.

Curious, I think directly the opposite and I say it as a programmer rather, than "packager".

Unused files in the program should not remain, how "dead weight".

"Premature Optimization Is the Root of All Evil", as it is said among programers. Is size of old data really a problem, especially while compared to CO package size? I prefer to wait for CO becoming part of official data repo. I was already disscused with onetwothree, if I remembered it well.

If I ask for help, then I’m sure that this is necessary. If you do not want to help, just say. This is better than if you promise, and then do not keep the promise (with a similar request, such a case already happened).

As You can see, I dont promise anything. Just follow an approach, that "who asks, dont strays", as we say in Poland. If it irritates You, I can understand it, as You are rather busy man and apparently You dont like to change once set direction. However, I'm still unconvinced, so probably I wont help with it. At least not now.

[Art Blos]

Indeed. But it's some strange old format. I'll start to experimenting with Arch Linux format, and ask page admin to post packages mainained by onetwothree.

Yes, it is necessary.

Because otherwise You have to mess with existing data, which, at least on most Linux distros, will conflicts with package information. And, of course, it force You to call for help in order to support various OSs.

Ok, try to come up with a way without a script. But keep in mind that for installation on Windows everything will remain the same.

Curious, I think directly the opposite and I say it as a programmer rather, than "packager".

This is already a question of approaches to work. It is pointless to argue here.

"Premature Optimization Is the Root of All Evil", as it is said among programers. Is size of old data really a problem, especially while compared to CO package size? I prefer to wait for CO becoming part of official data repo. I was already disscused with onetwothree, if I remembered it well.

It's not about the size. I am a perfectionist and can not stand anything superfluous. I will not go into details, but such an option will complicate my work.

As You can see, I dont promise anything. Just follow an approach, that "who asks, dont strays", as we say in Poland. If it irritates You, I can understand it, as You are rather busy man and apparently You dont like to change once set direction. However, I'm still unconvinced, so probably I wont help with it. At least not now.

Clear. Well, at least thanks for the info.

[selden]

"snap" seems to be a relatively new install format which works for most, perhaps all, linux distributions.

See https://itsfoss.com/install-snap-linux/
and https://snapcraft.io/

[Anthony_B_Russo10]

The Linux distros that would have to covered are Ubuntu (and its based distros like Linux Mint and Kubuntu), Debin, Arch, Fedora (OpenSUSE, Red Hat, and CentOS (Red Hat Based)).

[Markerz]

it should be trivial to write a shell script for macOS, however, different versions of Celestia needs to be handled differently (between 1.6.1 and oncoming 1.6.2, 1.7.0 etc).

I didn't test 1.6.1 since 32bit applications don't run on my Mac now. I have fixed some bugs on 1.6.x branch on GitHub, so it can now choose to load Celestia Origin files. actually with 1.6.2, you just designate the location of celestia.cfg and the data directory in a dialog, there's no need to replace files (and in fact you can't), no shell script is needed!

I'm looking to release 1.6.2 sooner, but it depends on the plan the other maintainers have.

[Art Blos]

it should be trivial to write a shell script for macOS, however, different versions of Celestia needs to be handled differently (between 1.6.1 and oncoming 1.6.2, 1.7.0 etc).

At the moment, I'm based only on version 1.6.1. I will focus on later ones after the official release.

[selden]

The Linux distros that would have to covered are Ubuntu (and its based distros like Linux Mint and Kubuntu), Debin, Arch, Fedora (OpenSUSE, Red Hat, and CentOS (Red Hat Based)).

snap is supported for recent releases of all of the linux distributions mentioned, plus many more.
See https://snapcraft.io/docs/installing-snapd

snap is not supported for Windows or MacOS. You'd have to run a Linux VM to use a program that's in snap format.

[onetwothree]

snap is supported for recent releases of all of the linux distributions mentioned, plus many more.

Would you like to volunteer?

[onetwothree]

Debian 9 & 10 and Ubuntu 16.04 & 18.04 packages are available from bintray. See https://bintray.com/celestia/releases-deb/celestia/view/readmore#read for installation instructions

[selden]

snap is supported for recent releases of all of the linux distributions mentioned, plus many more.

Would you like to volunteer?

Sorry, I don't have enough time available to do that.