Debian package part 2

Archives Forums/Linux Discussion/Debian package part 2

marksibly(Posted 2009) [#1]
[NOTE]
This is a Linux packaging discussion from the DevTeam forum that really belongs in public.

For my part, my main concern is that Linux BlitzMax can somehow install dependent packages - hence the initial excitement over an rpm package.

However, if this can also be accomplished in a more distro neutral way via a script, then even better.
[/NOTE]

Hi,

Having second thoughts about this...

How many of our users *can't* use debian packages?

Does this mean we need to provide a tar.gz too?

If so, forget it - I'm only doing the one!


SebHoll(Posted 2009) [#2]
Debian package! Debian package! I'm so exciteed that BlitzMax is getting all grown up!!! And I spent a few hours putting icon support into FLTKMaxGUI just for this, so you better... :P jk

How many of our users *can't* use debian packages?

Don't you just double-click? :P


marksibly(Posted 2009) [#3]
Hi,

> Don't you just double-click? :P

On debian systems, yes.

On redhat systems, I need to provide an rpm.

On other systems...who knows.

One thing I can guarantee, whatever we leave out, *someone* will want!

I am getting serious release fatigue here...it feels like I've been building/tweaking/packaging/uploading forever and it has to stop now.

So sorry, no .deb this time round.


Brucey(Posted 2009) [#4]
Assuming you need root rights to install the .deb into /usr/* , what rights would one need to be to build modules, considering of course that BlitzMax/mod would be in /usr/* ...

Locating in /usr/* also implies that the same BlitzMax would be available to all users on the box. What would happen if user B tried to build modules after user A had previously? (this time assuming that you don't need to be root to build them).

Anyway, I prefer to have BlitzMax in my /home/* folder. But each to their own? :-)


Mark Tiffany(Posted 2009) [#5]
Is this of any help?

http://kitenet.net/~joey/code/alien/

(I have zero idea, but if you can create a deb that works, and that you can prove also works when "alien"-ed, then either you could "alien" it and host an RPM, or leave instructions for the user to do same?


Mark Tiffany(Posted 2009) [#6]
Hi, finally tried using this on my Ubuntu VM, and I get:

Error: dependency is not satisfiable: libstdc++6-4.3-dev

I can't see this specific package listed anywhere...what's going on? I'm guessing 6-4.3 has been pulled...

Should the dependency be on libstdc++6-dev, is this the "generic" version that ensures you get the most recent version? It seems installing this also ensures g++ is pulled in?


Mark Tiffany(Posted 2009) [#7]
Hmm, possibly not seeing the libstdc++6-4.3 version because I am on 8.04 (and can only see 4.1 and 4.2 versions). Upgrading to 8.10 now, and expect to see 4.3 appear.

Even if the upgrade fixes the issue, suggest that unless there's a specific need for that version, shouldn't it be changed to libstdc++6-dev, and that will (presumably?) bring in the latest version available...


Mark Tiffany(Posted 2009) [#8]
Confirmed - 6-4.3 is not available on 8.04 version of Ubuntu (the LTS version), but 6-4.3 is available on 8.10 +. So really need to find how to specify it generically, not specifically.


Mark Tiffany(Posted 2009) [#9]
Why isn't g++ just listed as a dependency?

g++ package is needed for linking, and requiring g++ then brings in the latest version of g++ (g++-4.3 for me), which in turn ensures the latest libstdc (libstdc++6-4.3-dev)...


marksibly(Posted 2009) [#10]
Hi,

Whew, already glad I didn't try to release a .deb!

But yes, depending on g++ to import the correct libstdc++ for us is a good idea.


Mark Tiffany(Posted 2009) [#11]
For reference if you decide to revisit the .deb idea (which I think you should), it would probably be as well to set the BMXPATH environment variable (if you can in a .deb : seems like a reasonable thing to want to do!), seeing as issues have been seen in 1.33rc's with putenv_ not storing BMXPATH.


Jim Teeuwen(Posted 2009) [#12]
Creating packages for all the unices out there is a major hassle and time much better spent doing useful stuff.

Personally I much prefer getting blitz in a tar.gz archive, so I can move it to wherever I want. Also not having to dive deep into my filesystem to change modules is a definite plus. Mostly because my current setup has me running several blitz versions for windows and linux from the same root dir.
This saves me a lot of hassle having to remeber all the different paths it is installed in per OS.


Htbaa(Posted 2009) [#13]
I think most Linux users are comfortable enough with .tar.gz. No need for root access and it makes it very easy to run different versions of BlitzMax, if one would want to.

When you start with .deb packages then others want .rpm and whatever other flavor is out there. Stick with .tar.gz.


slenkar(Posted 2009) [#14]
agreed, you have to know about installing packages anyway


*(Posted 2009) [#15]
As a question, why not release a standard tar.gz and have a .sh script check for installed files required by Max this could flag up packages the users need to install to get running.

The main reason for that is otherwise you will need to create packages for loads of releases of linux, I had this problem with Elite on linux till my linux bod 'Lucifer[SD]' decided that we should just do a tar.gz and a .sh file in there checks to make sure everyone has everything required to run.

I think PB does this as well with its linux releases.


slenkar(Posted 2009) [#16]
What I do, is run the program in terminal and if it doesnt have the dependency if tells you.
You cant run the program from the same directory in terminal, you have to run it from the parent directory or just use ./ in front


Jim Teeuwen(Posted 2009) [#17]
I'm trying my hand at a general purpose install.sh script as Edzup[SD] suggested.

For this to work, I need some information on the package manager capabilities and blitzmax dependencies of the major unix distros.

For Ubuntu i've got it covered.
I'm looking for info on Fedora Core, Debian (this is likely the same as ubuntu), Gentoo, Redhat and possibly even MacOSX, provided it supports a command-line package manager.

In order to have the script detect which distro is running I am using a simple array of distro names and compare it to the output of '$ uname -v' until I find a match.

'uname' is a standard unix program which outputs distro name/version, kernel version and architecture type (32/64-bit), so this is a handy way to detect the distro on all unices (including macosx).

These are some outputs for 'uname -v' I have already:
- MacOSX: Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386
- Ubuntu: #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009
- Array kernel (asus eeepc): #0array1 SMP Mon Feb 23 15:02:03 MST 2009

So in order to support a smooth install on other distros, I need the outputs of 'uname -v'. Google isn't very helpful in this regard and I don't plan on downloading all of them and running them in a virtual machine, although I will if I have to. It would be nice if people here can toss in some info if they happen to work with any of the distros listed above (or one I havn't considered yet).

The script is structured to offer an easy way to include support for any new distros and it supports different handling of installations on 32-bit vs. 64 systems. This is a requirement for Ubuntu, and I imagine some other systems as well.


Jim Teeuwen(Posted 2009) [#18]
Here is the initial version. So far it only implements install/uninstall support for Ubuntu. there are empty stubs for some other distros, which have to be implemented in the coming days for as far as I can.

Note that macosx is included in the list, but i'm unsure if it's possible to install all the osx requirements (xcode?) through a shell script. Some input from a mac user could help here.

Running the script without command line options performs the install for the distro it is running on. You can force the install with the -i flag, or uninstall everything with the -u flag.

I also switched from using 'uname -v' to 'uname -a' for identifying distributions. Reason being that gentoo has no useful output with 'uname -v'.




I've tested it on clean installs of Ubuntu 9.04 64 bit and Eeebuntu 3 32-bit (also based on ubuntu 9.04). Installation and uninstallation worked on both without problems.


markcw(Posted 2009) [#19]
Note that macosx is included in the list, but i'm unsure if it's possible to install all the osx requirements (xcode?) through a shell script. Some input from a mac user could help here.

Yes, forget about Mac OS X Jim, xcode takes care of all BMax dependencies.


Jim Teeuwen(Posted 2009) [#20]
Alright. I tossed out the identification of individual distros because there is no sensible standardized way to do it across different linux versions.

The script now simply checks for the presence of any of the supported package managers (aptitude, emerge, yum, etc) and performs installs based on these. This is proving a lot easier and it doesn't matter which distro we are running on.

version 0.2b:



*(Posted 2009) [#21]
This will make it easier for the whole blitzmax experience :)


_Skully(Posted 2009) [#22]
Nice work

It still bewilders me that there is no package creator out there that creates install packages for all Linux distributions... I`m sure there would be a market for it.

cheers.


slenkar(Posted 2009) [#23]
interesting, does it support 'pacman' (from arch linux) and puppy linux?


Jim Teeuwen(Posted 2009) [#24]
Not yet. I have no experience with any package managers besides debian's aptitude. It's easily added though.

If you can supply a version of the following function, but which uses your prefered package manager, I'll add it to the script.

inst_pacman()
{
	## add pacman code here
}

# This is the working version for aptitude:
inst_aptitude()
{
	echo "[i] building package list...";
	if [ $IS_64_BIT -eq 1 ]; then
		PKG_LIST="gcc-multilib g++-multilib libxxf86vm-dev libglu1-mesa-dev x11proto-core-dev x11proto-gl-dev x11proto-kb-dev libxxf86vm-dev libasound2-dev libidn11-dev libxft-dev x11proto-xext-dev";
	else
		PKG_LIST="gcc g++ libxxf86vm-dev libglu1-mesa-dev x11proto-core-dev x11proto-gl-dev x11proto-kb-dev libxxf86vm-dev libasound2-dev build-essential libidn11-dev libxft-dev x11proto-xext-dev";
	fi
	echo "   $PKG_LIST";

	if [ $DO_INSTALL -eq 1 ]; then
		echo "[i] installing...";
		if [ $IS_64_BIT -eq 1 ]; then
			## install ia32-apt-get separately.
			## The other packages require this one to be installed and ready.
			sudo apt-get install ia32-apt-get;
		fi

		## We can pass all of the packages to aptitude in 1 go,
		sudo apt-get install $PKG_LIST;
	else
		echo "[i] uninstalling...";
		## We can pass all of the packages to aptitude in 1 go,
		sudo apt-get --purge remove $PKG_LIST;
		
		if [ $IS_64_BIT -eq 1 ]; then
			## uninstall ia32-apt-get separately.
			sudo apt-get --purge remove ia32-apt-get;
		fi
		
		## These 2 commands tell aptitude to clean up any unused packages
		## still lingering around the system. They make sure we do not leave
		## any orphaned packages behind.
		echo "[i] performing aptitude cleanup...";
		sudo apt-get autoremove;
		sudo apt-get autoclean;
	fi
	return $?;
}


The above will also go for Gentoo's 'emerge' and redhat's 'yum'. If anybody has experience with those, by all means come forth.

Also, this script will probably better come to it's right in the Linux forum instead of here in the Devteam forum. it really is more of a community responsibility than BRL's. When it is complete, they can always decide to include it in linux packages of blitz. I think it's best we move this discussion to the Linux forum. Considering the EULA in this forum though, I am not sure if Mark will allow it.


slenkar(Posted 2009) [#25]
its just pacman -S
instead of sudo apt-get install

I dont know enough about pacman to make a script but I dont really need it. Begginer users are probably going to be using Ubuntu anyway.


Jim Teeuwen(Posted 2009) [#26]
Yes, but are the package names the same? for Gentoo for instance, the packages listed in the inst_aptitude bit do not work.


marksibly(Posted 2009) [#27]
Hi,

This is a Linux packaging discussion from the DevTeam forum that really belongs in public.

For my part, my main concern is that Linux BlitzMax can somehow install dependent packages - hence the initial excitement over an rpm package.

However, if this can also be accomplished in a more distro neutral way via a script, then even better.


N(Posted 2009) [#28]
What you might be able to do is just write a script that checks for the existence of certain package managers (e.g., apt, emerge, rpm, etc.) and use one of those available to install dependencies. This would probably require a user's authentication in most cases (e.g., apt needs to be run through sudo - not sure about emerge and rpm, I expect there should be some way to install some things into a home directory though). It would probably have to be a simple script just to allay any fears of the script doing something malicious (since reading a simple script makes it fairly easy to determine whether or not something bad will happen out of view), for those people paranoid about running it.


Jim Teeuwen(Posted 2009) [#29]
That's exactly what my script does, nillium. But as stated, the names of the packages differ per package manager, so I need to get that cleared up first. The Debian/Aptitude bit is working though.

The issue is mostly that I am only on Ubuntu most of the day, which means i'm stuck with Aptitude. I have run a few other linuxes throogh VirtualBox, to see how their package stuff works. But tbh having to learn a new distro + trying to figure out what packages blitz needs there is just a little too much for my taste. Specially since we already have many people using all those different distros.


edit: Updated the script in my previous post. I added stubs for 2 more package managers (urpmi and pacman).


Jim Teeuwen(Posted 2009) [#30]
Version 0.3b.

- More robust package manager checking.
- I researched the command line options used by all the supported package managers and added their respective implementations to the function stubs.

The only thing that is missing now is the actual names of the packages needed for each package manager (Except for Aptitude).

I still need these for the following package managers: rpm, emerge, pacman,yum.
Once i have these, the script should be done. It currently supports the following package managers: aptitude, emerge, yum, rpm, pacman.

This makes the script usable for (at least) the following Linux distributions:
- Debian + forks (including: ubuntu + forks, backtrack 4, Knoppix + forks).
- Gentoo + forks
- Redhat + forks (including: Mandriva)
- SuSE Linux + forks
- Fedora Core + forks
- Arch linux
- Puppy Linux

For a complete list of linux distros using the supported package managers, see: http://en.wikipedia.org/wiki/List_of_Linux_distributions




markcw(Posted 2009) [#31]
For yum in Fedora 11 use.

su -c 'yum install gcc-c++ libX11-devel mesa-libGLU-devel libXft-devel libXpm-devel'

See here.


markcw(Posted 2009) [#32]
For urpmi in Mandriva 2009 use.

urpmi gcc-c++ libx11_6-devel libmesaglu1-devel libxft-devel libxpm-devel

See here.


Jim Teeuwen(Posted 2009) [#33]
Excellent! I'll add it asap.

edit: Here we go. Version 0.4b.
- Still missing are the package listings for emerge and pacman.




skidracer(Posted 2009) [#34]
Hey Jim, I assume people wanting to distribute binaries of their blitzmax games could use a stripped down version of this approach?


Jim Teeuwen(Posted 2009) [#35]
This is strictly for getting blitzmax itself running, but if your app requires some packages to work on linux, then yes, you can use this script to do the same thing. Just make sure you have the required package names for each supported package manager.

Note that the packages my script above installs are the development versions. You do not need those to make a compiled game binary work.

edit: If the user has proper display drivers installed for their gfx card and sound support working in their Linux install, then chances are their dependencies will have been met sufficiently for your game to run.
Still, it couldn't hurt to have a script make sure and make suggestions accordingly before the game starts/is installed.


Jim Teeuwen(Posted 2009) [#36]
I just tested the script again on a fresh 64-bit install of a Ubuntu fork (CrunchBang) and I thought I'd try it without the ia32-apt-get package because it has a tendency to mess up my repository listings and system updates (ia32 breaks aptitude updates on vanilla ubuntu and all forks).

The install went fine and blitzmax runs without any problems. Compiling my apps works as well as building modules. So I am not really sure why the requirement for ia32-apt-get is in there. I am releasing a new version of the install script which has this dependency commented out. I would leave it in, but the fact that the ia32 support really screws with the package manager's functioning on all 64-bit Debian systems makes me believe we are better off without it.

Unless, of course, someone can convince me of it's absolute necessity.

version 0.5b



GaryV(Posted 2009) [#37]
I have tried to join the "dev", but I get no response to my emails, so I will post here.

Mark: What about using BitRock InstallBuilder?

BitRock InstallBuilder is a development tool for building crossplatform installers for desktop and server software. With InstallBuilder, you can quickly create professional installers for Linux, Windows, Mac OS X, Solaris and other platforms from a single project file and build environment. In addition to installers, InstallBuilder will generate RPM and Debian packages and multiplatform CDs/DVDs. Its new automatic update functionality makes it easy to deliver updates directly to your users once they have your software installed.


http://installbuilder.bitrock.com/index.html


markcw(Posted 2009) [#38]
For emerge in Sabayon 4.2 use.

sudo emerge -a libstdc++-v3 libX11 mesa-progs libXft libXpm

See here.

Also, I have updated your install script Jim T. I fixed a few mistakes and added new code to deal with su. This should be bug-free.

Updated on 9-8-09.




Jim Teeuwen(Posted 2009) [#39]
Cool. nice job!

Could you modify the 'version history' bit in the header to list your changes please? Will make it a bit easier to track what's going on :)
I also think it's fair you add yourself to the 'author' bit :p

We're getting there! Script is almost done.

I did notice a possible improvement in the root checking code. I don't think we need the script to be restarted once the 'su' command is issued. This means we don't have to unset the $PKGMGR varianle either.

...
if [ -z "$PKGMGR" ]; then
	echo "[e] Unable to find a package manager.";
	echo "    Supported are: ${PKGMGRS[@]}";
	exit 1;
fi

###############################################################################
## Check if root login is needed. Some distros use su and others use sudo.
## I am assuming distros using the same package manager use the same su/sudo syntax.
if [ `whoami` == "root" ]; then
	echo "[i] Logged in as root user.";
elif [ "$PKGMGR" == "yum" ] || [ "$PKGMGR" == "urpmi" ]; then
	echo "[i] Root access is required for $PKGMGR...";
	su;
fi
...


Once su has been issued and the user logs in, the script should be fine just continuing to the actual function call to inst_yum or inst_urpmi.

I am assuming that it is irrelevant with which user the script was started. This may be a wrong assumption on my part though, in which case, just ignore me :)


markcw(Posted 2009) [#40]
Could you modify the 'version history' bit in the header to list your changes please? Will make it a bit easier to track what's going on :) I also think it's fair you add yourself to the 'author' bit :p

Done. :)

I did notice a possible improvement in the root checking code. I don't think we need the script to be restarted once the 'su' command is issued. This means we don't have to unset the $PKGMGR varianle either.

Well I've removed the line exit 0; after su; now because it was confusing things. You see su ends the script anyway and although there is a way around this it looked complicated so I just decided to go with the simple option of getting people to re-run the script.

Also, the reason I unset the pkgmgr var is because in Mandriva urpmi isn't actually found until you've logged in as root, so to keep consistency and since su was exiting anyway I just used unsetting the pkgmgr var as a root login flag. Hope that makes sense.


Jim Teeuwen(Posted 2009) [#41]
Yup, it does. Thanks for clarifying :)


D4NM4N(Posted 2009) [#42]
.


markcw(Posted 2009) [#43]
I've added support for zypper in openSUSE to the script now, see here. This is version 0.7b, I'll update this post when/if I get pacman done.

Edit: added pacman packages, 16 Aug. See here.
Edit: added a bit to the root login code. That should be all from me now.




D4NM4N(Posted 2009) [#44]
@JimT

Nice script, it worked for me :)

(Ubuntu 64 9.04)


markcw(Posted 2009) [#45]
Jim T, you may want to put a reminder in the script for people to update their package database first. I forgot and was wondering why it couldn't find any packages.

Also, just to note that for apt 64-bit you don't actually need x11proto-core-dev and x11proto-kb-dev as they are dependencies of libglu1-mesa-dev.

Funny enough, I'm stuck getting MaxIDE to run on ubuntu 9.04 64-bit. Installing ia32-apt-get didn't help so I removed it again. I get this error message.

./MaxIDE: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory

I found this topic but there isn't a solution, I have got /usr/lib/libx11.so.6 (link) and libx11.so.6.2.0. Any ideas please?

Edit: well it suddenly works now. Weird as I didn't really do anything other than try 'sudo apt-get install ia32-libs' which was already there and I may have rebooted but I can't remember. Anyway happy days.


Jim Teeuwen(Posted 2009) [#46]
hmm I'm still not entirely clear on why the ia32 support is needed. I have done a clean ubuntu 64-bit install on 3 occasions now. I used the install script without the ia32 support to get blitz working without any problems. No error messages or missing dependencies.

I really need to know what exactly it is that requires the 32 bit libs and why before I reinstate them in the script. Reason being the huge problems it gives with the apt-get commands. It really ins't worth it if there is a way around this.


dawlane(Posted 2009) [#47]
I used the install script without the ia32 support to get blitz working without any problems.

Does that include fully rebuilding all the modules?


Jim Teeuwen(Posted 2009) [#48]
yup.


markcw(Posted 2009) [#49]
The libxpm-dev package was missing in the aptitude list.



jkrankie(Posted 2009) [#50]
I'm a linux noob, how do i execute the script?

Cheers
Charlie


jkrankie(Posted 2009) [#51]
i got it, sudo bash installstuff.sh -i
who knew!

Cheers
Charlie


markcw(Posted 2009) [#52]
You can use chmod to give the file exec permissions then run it with the "./" prefix which represents the current directory.
chmod u+x installstuff.sh
./installstuff.sh



jkrankie(Posted 2009) [#53]
ah, I got as far as chmod -x which didn't work. Linux is mildly different from Mac OS X terminal language-wise. I guess it'll take a bit of getting used to.

Cheers
Charlie


markcw(Posted 2009) [#54]
That would be because "chmod -x" means deny execute permission.

Typing "man chmod" brings up the manual for that command.
Also you need to know to stop shell processes like man with Ctrl+Z.
I prefer to use the web though, like http://ss64.com


jkrankie(Posted 2009) [#55]
No wonder. To be honest, i was trying to do it from memory. I guess i must have wanted something to stop being executed in the past and the line stuck.

Cheers
Charlie


Jim Teeuwen(Posted 2010) [#56]
Just for info: The script is tested and found to work with 64-bit Ubuntu 9.10 (Karmic).


Russell(Posted 2011) [#57]
The script works great (note: if you don't have sound in your compiled programs and your system is using pulseaudio, read this: http://www.blitzbasic.com/Community/posts.php?topic=93662 ), but it really should be included in the download package and labelled "Run Me First" or, better yet, run automatically upon installation.

Russell