Will there be an autopackage available for the Linux port?
Autpackage provides Linux users with an easy way of installing packages, a click & install like Windows users know it. Another advantage is that autopackage is distribution independent, so there won't be a need to package the port in rpm's, deb's, and such then. Check out the Autpackage website.
One more question, will SpringClient be created in GTK? If so, will there also be a QT3 frontend for us KDE users? Of course there are things like the GTK-QT theme engine, but that wouldn't be an ideal solution I think.
will there be an autopackage for the Linux port?
Moderator: Moderators
-
F for Fragging
- Posts: 24
- Joined: 07 May 2005, 17:33
Before I head to sleep, I'll answer all your questions!
It'll be autopackaged if you or someone else volunteers to autopackage it! It looks like you are the only one so far :)!
External to the actual engine, GUIs will be wxWidgets, which does not appear to have a QT binding.
It'll be autopackaged if you or someone else volunteers to autopackage it! It looks like you are the only one so far :)!
External to the actual engine, GUIs will be wxWidgets, which does not appear to have a QT binding.
I agree! Anyone who wants to produce packages for their favorite distro may do so themselves. The standard distribution of the game will be packaged in source-form most likely.coryrc wrote:Before I head to sleep, I'll answer all your questions!
It'll be autopackaged if you or someone else volunteers to autopackage it! It looks like you are the only one so far :)!
External to the actual engine, GUIs will be wxWidgets, which does not appear to have a QT binding.
-
F for Fragging
- Posts: 24
- Joined: 07 May 2005, 17:33
Well, I wasn't exactly volunteering to do it, but if no one else wants to do it, I will give it a try.coryrc wrote: It'll be autopackaged if you or someone else volunteers to autopackage it! It looks like you are the only one so far :)!
That's quite a conservative way of thinking.Ace07 wrote: I agree! Anyone who wants to produce packages for their favorite distro may do so themselves. The standard distribution of the game will be packaged in source-form most likely.
Compiling from source isn't user friendly. Most of the time I want to compile something from source I have to figure out which dependencies I need (dependency hell), and when I figured it out I need to download somewhere like over *devel* packages, which I only need to compile the source, and are useless after it has been compiled. Autopackages don't require the user to compile anything, and are more user friendly.
And if you rely on others to make packages for specific distro's, it will take some time, maybe a week or so, before it has been packaged.
For example, I'm using the Kubuntu Linux distro. I like to use the superkaramba program to place some widgets, so called superkaramba themes, on my desktop. Unfortunately some themes require version 0.36. However, I could only find version 0.35 in the apt repository. 0.36 was released over a month ago but it still wasn't packaged by my distro. So I had to compile it myself.
If you'd create an autopackage as well as a source package, users could immediatly install it without having to wait for their distro's packagers. Plus, it would prevent the waste of time on the distro's end, instead of every distro having to package it themself, one autopackage is enough.
A third reason are the strange bugs which are caused by distro-specific packages. Instead of one autopackage, a package is packaged by twenty distro's, thus the chance of bugs occuring increases 20 times. Sometimes packagers don't have a very good idea of what they are packaging. sometimes packages are simply broken. For example, I installed the eric3 Python IDE on my Kubuntu Linux distro. It won't start up so it's broken, and the problem hasn't been fixed for months.
If the developers create an autopackage they are in control, and the chance of bugs occuring is decreased.
Summarized:
- no more compiling from source. sometimes users are forced to compile from source and download a shipload of dependencies because their distro's packagers are slow.
- autopackage is user friendly, no compiling from source, just an easy windows like click and install procedure
- autopackages are available very fast, for example on the day of a new release, if the developers take it serious. It takes distro specific packagers a few days/weeks/months to package a new package, so some users will have to wait before they can play.
- autopackages will prevent a waste of time, a program only has to be autopackaged once instead of twenty distro's all packaging it themselves.
- autopackages give control to the developer and decrease the chance of bugs. If a bug occurs then the developer can fix it more easily.
I agree completely. Packaging the program in something would be good. However, the absolute MOST platform independent version will be source. That is the advantage of compiling things from source you know....
The disadvantage is that its a huge pain in the ass sometimes. That is why there will probably be RPM and DEB packages available eventually. That covers almost all of the Linux scene. If you want to package using something else, then it is up to you to do so.
The disadvantage is that its a huge pain in the ass sometimes. That is why there will probably be RPM and DEB packages available eventually. That covers almost all of the Linux scene. If you want to package using something else, then it is up to you to do so.
Autopackage are really userfriendly and even a complete linux noob can use it. It's not the case of source or even sometimes .rpm / .deb because those will always break in some strange cases. And i know quite a few people who use linux but don't really know how to compile, Usually those would like to install TA Spring easily.
With an autopackage you just doubleclick and it works. Inkscape and Gaim already use that system and it works quite well.
I think that until spring is released on linux i have the time to learn how to make autopackages :)
With an autopackage you just doubleclick and it works. Inkscape and Gaim already use that system and it works quite well.
I think that until spring is released on linux i have the time to learn how to make autopackages :)
Oh, you mean .run files? They install themselves kind of?
I guess I don't know what autopackage is....
RPM and DEB files are very easy. If they are in the right repository, you can update your entire computer with one command!
Source is a lot more complex, but not as much as you would think. Its only 3 commands after all. Linux needs to create an HTML file on the desktop about how to install stuff from source. Its more important to learn this concept than anything.
It would be cool to have some other form of package, but that is for someone else to mess with. We will surely give you the source, and we will probably give you a few binary packages. After that its going to be up to others to get packages made. =)
I guess I don't know what autopackage is....
RPM and DEB files are very easy. If they are in the right repository, you can update your entire computer with one command!
Source is a lot more complex, but not as much as you would think. Its only 3 commands after all. Linux needs to create an HTML file on the desktop about how to install stuff from source. Its more important to learn this concept than anything.
It would be cool to have some other form of package, but that is for someone else to mess with. We will surely give you the source, and we will probably give you a few binary packages. After that its going to be up to others to get packages made. =)
See by yourself :)Ace07 wrote:Oh, you mean .run files? They install themselves kind of?
I guess I don't know what autopackage is....
http://www.autopackage.org/flash-demo-install.html