Surely the paksets do not need any form of porting? They are just binary data that should work on any file system (the same build of pak128 works on Windows, Mac and Linux). Or does Haiku use some very strange file system which does not understand files and folders? To install pak128 on my Windows system I unpacked it from the link provided in the forums.
If this is not the case then there must be some portability issue.
1.) Yes, if you want you can call Haiku strange
. For about 2 years now, Haiku (or rather the Haiku nightly builds which will eventually become the next official alpha/beta release) has used a rather uncommon approach to package management (PM). Packages (.hpkg extension) contain a virtual file system that is virtually expanded during boot (that's different to unpacking a zip or another compressed archive). Content of all packages is merged and - for a user running Haiku - then looks almost exactly like a pre-PM Haiku file tree - with one very important exception: apart from your home directory almost all other directories are read-only. If you want to use a convenient way to install software (and also find it in your application menu) - and you therefore use package management - your application folders are also read-only - so you can't just expand your downloaded zip file there (same reason why the included .sh scripts to download paksets don't work out of the box). Of course, for a power user, it is still possible to copy the files to the appropriate "non-packaged" folders to get it to work, but that takes time and - believe me - only a dedicated simutrans user would go through it. For a user who browses HaikuDepot (the graphical frontend to the package manager) looking for "transport simulation" it is much easier to download and install a simutrans package and one of the available pakset files at the same time (having just the simutrans binary without a pakset doesn't make sense). Haikuporter is the tool used to produce these packages. It needs the aforementioned recipe files on the one hand to compile (or for pure data files to download and re-package) software and on the other to provide information about the software (homepage, source url, description, license, copyright,...) that is fed into HaikuDepot so that a user can learn about a certain package before he/she installs it. The recipe doesn't replace any license file, list of authors, etc that is part of the standard simutrans(-pakset) zip file it just gives the user an overview without having to actually download it or having to search through the source code. You can for example click on the license entry and read the license text or click on the homepage entry and visit the simutrans homepage to learn more about the project. As soon as a user decides to download and install the package, it is expanded and has - for the user - exactly the same directory structure as if it was installed in the traditional way (downloading/expanding the zip files in a folder under e.g. /system/apps/) on a pre-PM Haiku alpha 4 release, even the included config files can be edited (little trick that's included in the technical part of the recipe).
Update: Sorry, forgot to mention that at the same time a package with a compiled version is generated by haikuporter a source package is created containing the original source code (I think Haiku specific patches are included in a separate subfolder of the same package).
2.) The two pakset recipes that are already available for haikuporter just download a pakset zip from sourceforge, expand it, put everything in the correct virtual directory, make sure that config files can still be edited, and re-package everything as .hpkg. They might work for most of the pakset features on 32 and 64 bit systems. However, at least on Haiku 64 bit, you can't play scenarios if you don't compile the pakset yourself (see http://forum.simutrans.com/index.php?topic=14655.0
). That's not pak128 specific (I just didn't notice that the same is true for pak64 at first). For this reason, I provided updated recipes that make architecture specific pakset packages that include working scenarios on 32bit and 64 bit systems.
Pak128 features a loooot of objects from a loooot of authors, quoting them all should give something like this:
(from pak128.prototype/authors.txt)It's probably not up to date, as many objects were removed or added ... Then I think that "pak128 team" is the best choice.
If you insist I could actually list everyone (I think there's no size limit for recipes) - as long as I could also find out during which years those people were part of the pak128 team. But it's probably a better idea to just use "pak128 team". Otherwise the haikuporter guys may think that I'm going overboard
Except the topic creator post says this...Hence the information is only 4 months old.
Sorry, I don't understand what you mean (not a native speaker here). I was referring to the year of the first post in the pak128 member thread. From that I deduced that there must have already been a pak128 team in 2008. That closed the time gap between Tomas Kubes as author/maintainer/copyright holder/whatever until 2007 and the year (2009) when pak128 team was first mentioned in the pak128/pak128.prototype/doc /changelog.txt file. If there already was a pak128 team in 2004 (with Tomas Kubes as a member) I'll adjust the copyright entry for the haikuporter recipe accordingly. That's why I asked, I was not able to find it out myself and didn't want to use wrong copyright information.