Package Details: tinyandbig-hib 1.4.1_20130612-1

Git Clone URL: https://aur.archlinux.org/tinyandbig-hib.git (read-only, click to copy)
Package Base: tinyandbig-hib
Description: Tiny & Big: Grandpa's Leftovers - a 3D jump-and-slice platformer (Humble Bundle version)
Upstream URL: http://www.tinyandbig.com/
Keywords: 3D action game humble platformer puzzle
Licenses: custom:commercial
Submitter: smls
Maintainer: None
Last Packager: smls
Votes: 3
Popularity: 0.000000
First Submitted: 2013-06-05 14:26 (UTC)
Last Updated: 2015-07-09 14:45 (UTC)

Latest Comments

smp commented on 2013-07-15 09:07 (UTC)

@smls: Interesting point. Thanks for looking into it.

smls commented on 2013-07-15 09:03 (UTC)

@C5OK5Y Alright, I did some testing/benchmarking. While copying the files from $srcdir to $pkgdir increases makepkg execution time by around 35% on my system (compared to extracting them to $pkgdir directly), hardlinking them instead has very little overhead indeed. However, the PKGBUILD will now fail if $srcdir and $pkgdir are not on the same filesystem. I went ahead and made it use hardlinking for now, so --rebuild works (although I still don't quite understand why anyone other than the maintainer would want to do consecutive rebuilds of a package like this). If it turns out that having $srcdir and $pkgdir on different filesystems is a legitimate real-life usecase, I'll probably revert this change though.

smp commented on 2013-07-13 21:09 (UTC)

The usefulness of `makepkg --repackage` is directly related to the way you write the PKGBUILD. It enables you to skip doing the same thing while rebuilding the package - like compiling (not this case) or extracting a 700 MB data archive (definitely this case). Little practical use? I use it ALL the time (you might not use it because this PKGBUILD doesn't work with it) - you have no idea how many small bugfixing or testing/tweaking fixes can be applied with only a repackage needed to rebuild the application. Plus making hardlinks is not in any considerable way slower than moving files. When properly extracting the data archive in the build (or prepare) function and doing hardlinks in package(), I can build the package with `makepkg --repackage` in little over a minute, while completely building the package with `makepkg` takes almost 4 minutes! How is that little gain? As making the PKGBUILD work with `makepkg --repackage` doesn't affect people not using the package in any way, but massively benefits people who know how to use it, keeping such a bug in the PKGBUILD puzzles me. And finally, making PKGBUILDs incompatible with certain functions of makepkg is IMHO quite a bad habit.

smls commented on 2013-07-13 06:32 (UTC)

@C5OK5Y "incompatible with `makepkg --repackage`" Why would you want to use `makepkg --repackage` on a PKGBUILD that doesn't do any compiling? I'm not eager to make the installation slower for everyone, just to enable a theoretical use-case with little practical value. "sdl is not a dependency (verified with readelf)" Yes it is, readelf lies :) (Verified by temporarily removing sdl with `pacman -Rdd sdl` and trying to start the game.) I did apply the remaining suggestions though, thanks.

smp commented on 2013-07-12 16:35 (UTC)

@smls: I'd like to point out several things in the build files. Here[1] is a patch which implements everything I describe here. In the PKGBUILD, rather than removing the license.txt, you should install it into /usr/share/licenses/$pkgname/LICENSE. Then the PKGBUILD has an issue that it is incompatible with `makepkg --repackage` - this can be solved by extracting data.tar.lzma into $srcdir in build() and then either copying the extracted files into $pkgdir traditionally with install or make hardlinks with cp (in this case, when considering the size of the game files, preferred). xdg-utils is needed as a dependency because of the usage of xdg-icon-resource in the install file. sdl is not a dependency (verified with readelf). The install file: update-desktop-database only rebuilds the cache database of MIME types handled by desktop files - not needed in this case as the .desktop file doesn't change the handling of any MIME types. update-mime-database updates the shared MIME-info cache - this is not needed as the desktop MIME-info database wasn't changed. Finally (this is not included in the patch) you don't have to have the full path to the executable in the .desktop file, if the executable is in $PATH. [1] https://gist.github.com/C5OK5Y/e6a40ce69e97339a4d16

smls commented on 2013-06-15 08:26 (UTC)

@tomru Maybe. It's possible that executing... export force_s3tc_enabled=true ...in the terminal before running tinyandbig-episode1, will be enough to fix it, even without libtxc_dxtn installed. However, if this doesn't fix it (either the game still does not run, or it runs but with missing/corrupted textures), then libtxc_dxtn should indeed be added as a dependency. Can you please test, which case this is? (I can't test myself, because it only affects the Mesa based open-source drivers, whereas I'm using the proprietary ATI driver that has S3TC support already built-in.)

tomru commented on 2013-06-14 20:10 (UTC)

When running on intel graphics (at least on the HD 4000) the game won't run reporting "EXT_texture_compression_s3tc not supported!" Installing libtxc_dxtn fixes that. One for dependencies?