Linux Game Publishing
Heh... Now you have us making packages for EVERYONE and spending less time on developing ports...Originally Posted by makoto42
It's a nice idea, but in the end, you're not making it easier- you're making it more difficult on the vendors. Not a good idea, if you think about it.
The biggest problem that few people realize (even the people MAKING the distributions are on that list of people...) is that the packaging system on their pet distribution (Heh... I've got three so far... Ubuntu, Fedora, and Mandriva..) happens to be tied fairly tightly to that distribution- and that while it all works together nicely from a YUM, URPMI, or APT (or "FOO", for that matter...) repository or off their CD/DVD, once you try to pull in stuff from another distribution or from a non-source derived origin (say, GAMES...), you end up taking a chance on the things not working- or possibly messing the whole thing up badly enough that unless you know what you're doing, you're in for a reinstall.
I know, I've done this sort of thing before with Alien in the past. Not pretty.
It makes for a LOT more work than it's honestly worth, if you start thinking about it from that perspective- take a chance of fubaring their machine, or drop it in their home directory like we do and prep things THAT way. Which would YOU have?
Phoronix Test Suite Contributor
About time guys!
As for MojoSetup - sure, technically, it sounds great. One flaw (yes, I do consider it one) - it's terminal-based.
Hello, it even doesn't launch a terminal of it's own when you double-click on it. Forcing you to open a terminal, cd, and run it. Argh.
I really like the Loki installers, and hope this one is just as good.
Moderator
Maybe you should look at build services like openSUSE has. It's capable of creating packages for multiple distros and architectures in one easy to manage project.
The openSUSE Build Service already supports several Linux distributions including openSUSE, Debian, Fedora, Mandriva, SUSE Linux Enterprise, CentOS and Ubuntu with more distro's being added all the time.
Battle For Wesnoth
I think for binary only packages like game it makes sense to have a two path approach:
1) Plain installer:
Make the installer file executable, start the installer (doubleclick in the ide, ./installer.sh, whatever), have it installed where you are allowed to write with the normal users privileges. This is an approach which will work nicely for all who do not care about the distributions.
2) Option to extract files in no-GUI mode
Allow the package/installation be somehow extracted in a no-GUI mode. This leads to allowing package managers to do this extraction in a temp folder and just copy the files over to the distribution specific places. This does of course require ways to tell the binary where the games datafiles are located. Each distribution could then write an own tiny shellscript, which is put in the normal $PATH and just calls the normal binary with the params needed.
I think with such an approach the games vendor (or company porting) "just" has to follow the normal path setups that every program should adhere to anyway, plus provide a no-GUI mode in the installer, that basically performs an installation in a temp folder whichs content can afterwards be copied around. I think basically every package manager does allow a procedure like this. Of course the distributions do have to provide their packager files which handle those copying, but that is a job for the distributions maintainer.
Kanotix Developer
I don't know this one, but usally every .run file is made with makeself.sh. The nvidia installer is derived from an older version (1.6.0) and the ati installer from a newer one (2.1.3). I patched the ati installer to support lzma - I could do that for any newer makeself installer and all have an option to extract only (-x).
Hint: you find the makeself.sh used by nvidia when use -x at usr/bin/makeself.sh - this is used when you use the --add-this-kernel or --apply-patch options...
Last edited by Kano; 02-27-2008 at 06:04 AM.
Senior Member
Svartalf: will LGP be adapting older LGP titles to suit the new installer?
Will the new installer source code be released?
Ryan Gordon - Linux Game Porter
http://xkcd.com/386/
No, it's not. We shipped the UT3 server with just the stdio UI because most admins were hostile to the idea of having an installer at all (they just wanted a .tar.bz2, Epic's legal required that we show a EULA, though). Since most admins would be installing it over a ssh session, basic text to stdio was the best plan.
My understanding is that TTimo did something similar with ET:QW...I think at the time he shipped it with the ncurses UI.
MojoSetup also has a GTK+2 UI, and other variations on the way, and has the ability to choose the best UI for the environment at runtime.
Hence the dilemma of needing to set an executable bit on an executable.
Windows gets around this because they just look for the .exe extension, Mac OS X gets around this because they can ship real disk images with the executable bit set. Linux is...lacking for a decent solution at the moment. makeself gets around this by wrapping your installer in a self-extracting shell script and praying that the desktop does the right thing when you click it but that has a different set of problems.
Eventually this will need a better solution that involves improvements at the distro layer.
It looks like they reached rough parity with the icculus.org branch of loki_setup. I'd be curious to see the changes.I really like the Loki installers, and hope this one is just as good.
--ryan.
Ryan Gordon - Linux Game Porter
While I'm rambling here...
...might as well hit all the other comments, too...
MojoSetup does both of these things. The no-GUI mode option you mention looks something like this in the new UT3 server patch:I think for binary only packages like game it makes sense to have a two path approach:
./UT3-linux-server-02202008.bin --ui=stdio -noreadmes --i-agree-to-all-licenses
--destination /where/i/installed/ut3-dedicated
It's a little chatty, but it gets the job done.
In the worst case, they're just self-extracting zip files at the end of the day:
unzip ./UT3-linux-server-02202008.bin
cp -R data/* /where/i/installed/ut3-dedicated/
I would hope so, it's based on someone else's GPL code.Will the new installer source code be released?
MojoSetup comes with its own uninstaller now, and will write out loki_setup-compatible XML files, so you can use it with loki_update, etc.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.
Granted, all of this work is recent, so it's not like LGP could sit around and hope it got done when they had titles to ship. I pointed out MojoSetup to Michael when I first announced it, and he mentioned he already had someone working on updates to his existing loki_setup fork...and frankly, MojoSetup wasn't ready for prime time when that conversation happened, so moving forward with updates to lgp_setup was definitely the rational course of action (although I'm not sure forking from loki_setup was all that wise, if that's what's happened here).
I really would like to see the actual changes, since the article here listed things that have been in loki_setup for some time (GTK+2 port and hackish xdg-menu support shipped with Google Earth, large file/install support shipped with UT2003, etc). If nothing else, I'd like to get things merged back into loki_setup where reasonable.
--ryan.
Linux Game Publishing
Heh... Hi Ryan! Glad to see you on here.
I think I'll ask Michael when the release schedule is for the mods when I get a chance. He's not one to dodge that GPL/LGPL thing- he's already given out a network programming stack for games under the LGPL.I would hope so, it's based on someone else's GPL code.
I've no idea what he's done on that one. I've not looked at anything except the code on one his titles that went a bit sideways on him of late. And I'd concur on the wisdom of the forking of the code. I DO know that I would rather use MojoSetup in the long term, though- it's a MUCH nicer tool for the job than what we have right now in the stuff we're discussing.Granted, all of this work is recent, so it's not like LGP could sit around and hope it got done when they had titles to ship. I pointed out MojoSetup to Michael when I first announced it, and he mentioned he already had someone working on updates to his existing loki_setup fork...and frankly, MojoSetup wasn't ready for prime time when that conversation happened, so moving forward with updates to lgp_setup was definitely the rational course of action (although I'm not sure forking from loki_setup was all that wise, if that's what's happened here).
Heh... Same here, honestly. While Mojo's a better tool, there will be people that'll want to use the old Loki setup engine. It may be that it's all of what you're mentioning with tweaks to make it play nice within the build environment toolchains we end up using.I really would like to see the actual changes, since the article here listed things that have been in loki_setup for some time (GTK+2 port and hackish xdg-menu support shipped with Google Earth, large file/install support shipped with UT2003, etc). If nothing else, I'd like to get things merged back into loki_setup where reasonable.
Linux Game Publishing
As annoying as that all is, as a security consultant (heh...other hat getting put on right at the moment...), I think that this is an ill-concieved idea, really. One of the things that provides security is that feature of Linux that it can't just run anything dropped on the hard disk without some user intervention. Under Windows and MacOS, you can get zapped with spyware rather readily and easily through that vector.Hence the dilemma of needing to set an executable bit on an executable.
Windows gets around this because they just look for the .exe extension, Mac OS X gets around this because they can ship real disk images with the executable bit set. Linux is...lacking for a decent solution at the moment. makeself gets around this by wrapping your installer in a self-extracting shell script and praying that the desktop does the right thing when you click it but that has a different set of problems.
Eventually this will need a better solution that involves improvements at the distro layer.
How do you think that Sony managed to put that rootkit on all their audio CDs? Through automatic things like that. Nice idea- very unintended consequences.
Posting Permissions
Reply With Quote