LGP Has A New Linux Game Installer

[phoronix]

Phoronix: LGP Has A New Linux Game Installer

Linux Game Publishing, the company behind porting such games to Linux as Cold War and X2: The Threat, has prepared a new Linux GUI installer for its forthcoming titles. While this new installer doesn't feature any overwhelming additions, it has been written finally to use GTK2 and other new functionality for this setup utility.

http://www.phoronix.com/vr.php?view=11899

[makoto42]

Oh great, exactly what I want, the Windows style of installing software to gain mindshare in Linux.

One of the major gripes I have with Windows is software install/deinstall is so haphazard with umpteen different installers and deinstallers that don't always register with add/remove programs correctly. Under most linux distributions, much better package managed approaches are available to leverage. The significant downside, of course, being you cannot install/deinstall without root privilege, and no package manager makes concessions such that is easily accomodated (you can do so, but it becomes more complex than a desktop user should be expected to deal with), and that remains one reason for the installer I suppose.

Without knowing more about the company, I hope they at least provide debs and rpms as well as this installer. I don't want to see one of my favorite aspects of Linux distributions not be leveraged for all my software. Making a yum and apt repository available would be even smoother for patches.

[Svartalf]

One of the major gripes I have with Windows is software install/deinstall is so haphazard with umpteen different installers and deinstallers that don't always register with add/remove programs correctly. Under most linux distributions, much better package managed approaches are available to leverage. The significant downside, of course, being you cannot install/deinstall without root privilege, and no package manager makes concessions such that is easily accomodated (you can do so, but it becomes more complex than a desktop user should be expected to deal with), and that remains one reason for the installer I suppose.

You're probably an end user. What you DON'T know is that each distro, RPM based or DEB based happens to be a minefield for providing a "universal" package. Each one has slightly differing rules for where things go. And this doesn't even get into Gentoo or similar distributions which doesn't HAVE a packaging system like RPM or DEB but pull from source trees and builds everything.

You don't see the "nightmare" because you typically go with Red Hat prepared RPMs or SuSE prepared RPMs. DEBs tend to be a wee bit cleaner, but it's NOT assured that you're going to get consistent results, even if they're not "part of the package system". The installer, typically installs the game to your home directory unless you override that by installing as root, where it drops it in /usr/local usually. You want games installed in your home directory unless you've got a multi-user system anyhow.

Without knowing more about the company, I hope they at least provide debs and rpms as well as this installer. I don't want to see one of my favorite aspects of Linux distributions not be leveraged for all my software. Making a yum and apt repository available would be even smoother for patches.

You know what? Get them to be consistent amongst themselves and you might see that. We're not participants because there's no easy way for someone to DO that unless you're part of the source tree for the distribution or you're making a Red Hat, SuSE, Ubuntu, Debian, etc. package. So...either we snub a bunch of people, or we make an app installer that's not part of the packaging system. Take your pick.

[puntarenas]

One of the major gripes I have with Windows is software install/deinstall is so haphazard with umpteen different installers and deinstallers that don't always register with add/remove programs correctly. Under most linux distributions, much better package managed approaches are available to leverage.

Same here, but this installer aims for proprietary games and I wouldn't mind it messing around in my home directory, while the system stays clean.

[skoruppa]

hmm ROTFL. Long, LONG, LOONG time ago (when orginal loki installer was updated to gkt2) I wrote to LGP. I sugested to change installer to gtk2. The answer have been very funny... somethink like this "not all people have gtk2.. bla bla bla. We are not planing update of installer" yeaaah more people have gtk1 -_-".
Ow, and this new installer looks like normal loki installer on gtk2 :P

But after all, its nice to (finally) see installer in gtk2

[joshuapurcell]

So it is interesting that LGP didn't use the Mojo installer. Does anyone have any info on why LGP chose not to use the Mojo Installer and instead update their old installer seperately?

Also, for some reason I thought both installers were from the same codebase at one point... I guess I thought this was the case since both installers seemed so similar to me.

[makoto42]

You're probably an end user. What you DON'T know is that each distro, RPM based or DEB based happens to be a minefield for providing a "universal" package. Each one has slightly differing rules for where things go. And this doesn't even get into Gentoo or similar distributions which doesn't HAVE a packaging system like RPM or DEB but pull from source trees and builds everything.

You don't see the "nightmare" because you typically go with Red Hat prepared RPMs or SuSE prepared RPMs. DEBs tend to be a wee bit cleaner, but it's NOT assured that you're going to get consistent results, even if they're not "part of the package system". The installer, typically installs the game to your home directory unless you override that by installing as root, where it drops it in /usr/local usually. You want games installed in your home directory unless you've got a multi-user system anyhow.



You know what? Get them to be consistent amongst themselves and you might see that. We're not participants because there's no easy way for someone to DO that unless you're part of the source tree for the distribution or you're making a Red Hat, SuSE, Ubuntu, Debian, etc. package. So...either we snub a bunch of people, or we make an app installer that's not part of the packaging system. Take your pick.

I'm a developer/packager supporting Fedora, RHEL, SuSE, and Ubuntu. I'm all too aware packaging can be a nightmare, and the systems don't make it easy to make one package to rule them all, but your first few words 'you're probably an end-user' are precisely why I go through the pain and endure the nightmare, for a sane user experience. The problem with making your solution equally palatable to Ubuntu, Fedora, SuSE, Gentoo, Linux from scratch, Slackware, etc is that in the end you make something equally unpalatable to them all. As a packager I pick and chose my battles so that the largest portion of my userbase gets a great experience, while others deal with the lowest common denominator that many would have only provided in the first place. It's the singular thing I adore about AMD's drivers, the packaging (and dkms) straight from the vendor, while the nVidia is a mild annoyance to maintain. Adobe one ups AMD on a Fedora system with a yum repository, a great thing for applications to hook patches into.

Another suggestion: have the arbitrarily complicated set of distro-specific packages and your fancy GUI a frontend to install the packages as appropriate. That caters to both crowds, and I can ignore the GUI and those that use the GUI still get the integrated experience.

[niniendowarrior]

You're probably an end user. What you DON'T know is that each distro, RPM based or DEB based happens to be a minefield for providing a "universal" package. Each one has slightly differing rules for where things go. And this doesn't even get into Gentoo or similar distributions which doesn't HAVE a packaging system like RPM or DEB but pull from source trees and builds everything.

You don't see the "nightmare" because you typically go with Red Hat prepared RPMs or SuSE prepared RPMs. DEBs tend to be a wee bit cleaner, but it's NOT assured that you're going to get consistent results, even if they're not "part of the package system". The installer, typically installs the game to your home directory unless you override that by installing as root, where it drops it in /usr/local usually. You want games installed in your home directory unless you've got a multi-user system anyhow.



You know what? Get them to be consistent amongst themselves and you might see that. We're not participants because there's no easy way for someone to DO that unless you're part of the source tree for the distribution or you're making a Red Hat, SuSE, Ubuntu, Debian, etc. package. So...either we snub a bunch of people, or we make an app installer that's not part of the packaging system. Take your pick.

I've handled these things first hand and I certainly don't like the packaging nightmare. I find interesting though that LGP didn't go for Mojo. I don't find any fault on LGP on this install issue. It's simply a means to an end.

Now, I would dread this news if this was the big coup that Svartalf was hyping us all for.

[Svartalf]

Now, I would dread this news if this was the big coup that Svartalf was hyping us all for.

Not on a bet, it's not. I wouldn't have wasted either my time or any of yours if it was this...

[Svartalf]

So it is interesting that LGP didn't use the Mojo installer. Does anyone have any info on why LGP chose not to use the Mojo Installer and instead update their old installer seperately?

Also, for some reason I thought both installers were from the same codebase at one point... I guess I thought this was the case since both installers seemed so similar to me.

Mojo's RADICALLY different in many ways. Better, probably, but it's definitely NOT the same beastie. Nor. do I believe, are they compatible with each other.

LGP has an installed title base out there. We'd have to come up with a converter for the uninstall/patch system already in place with the Loki derived LGP installer/patcher system. Not that we couldn't have done this, but I suspect Michael Simms is thinking in terms of the medium term answers here.