Laserdisc Emulator
1) I reviewed the 'cube' package and noticed it was installed to opt with a script that runs the executable, but the directory is also writable for the games group. Since my script is copying/creating directories in the $HOME folder should I store the files and executable in /usr/share?
2) I screwed this up. Originally I wanted to install the library in /usr/lib, but daphne wasn't able to find the library.
A new version of DAPHNE, a laserdisc arcade game emulator, has just been released under the GPL, featuring full mpeg2 support. A total of ten laserdisc arcade games are playable including Dragon's Lair, Space Ace, and Cliff Hanger. A new version of DAPHNE, a laserdisc arcade game emulator, has just been released under the GPL, featuring full mpeg2 support. A total of ten laserdisc arcade games are playable including Dragon's Lair, Space Ace, and Cliff Hanger.
It only seems to find it if it's in the same folder as the daphne executable. I'm sure I'm missing a step to make it see the library. I'm still new to linux. If it's in opt or share. The prefix should be prefix=/opt or? Cara menghapus file yang tidak bisa dihapus dengan software programs. Thanks for your comments, I still need to learn a lot more about linux and arch packages.
See for basic guidelines on where to put what. I'm inclined towards putting this program in /usr/share/$pkgname. I'm not sure but if moving libvldp2.so file to the daphne directory works, it doesn't seem to matter much what prefix is set at. I'd place the install command for the library in the same part of the PKGBUILD, but that's a personal preference. I've looked at the makefiles and think the problems during running might come from the DLAGS they use. Almost all Arch packages use '-march=i686 -O2 -pipe' as compile flags.
From the look of things the authors of the code need to learn a bit about using configure/make/install or the modern successor scons. It's not uncommon that the tough part in creating a PKGBUILD is fixing hard-coded parts of the source code. 1 last comment: gcc is so common for an arch installation that it's rarely put in makedepends. All in all, i'd say this is a good PKGBUILD. This is a relatively minor point, but your depends array is not in compliance with the standards. You apparently filled it in based on the compilation information in the source tarball, which is a good starting place.
However, this often leads to redundant items, since you shouldn't list items that are required by other items present in the list. For example, libvorbis requires libogg, so libogg can be removed from the depends list of daphne. I find the easiest way to sort these dependencies out is to start with the complete list, as you have done, and then run 'namcap' against your Arch package, i.e.
$ namcap daphne-0.99.7-1.pkg.tar.gz daphne E: Dependency detected and not included (gcc) from files ['usr/share/daphne/daphne'] daphne W: Dependency included but already satisfied (sdl) daphne W: Dependency included but already satisfied (libogg) daphne W: Dependency included but already satisfied (libvorbis) This tells us that you can remove sdl, libogg, and libvorbis. Checking with 'pacman -Qi sdl_mixer', we can confirm that these are already required by sdl_mixer. The namcap script is not foolproof, but one of the things it does well is chew through the dependencies of your installed packages and find any redundant depends items. It doesn't seem to account for how likely Arch users are to already have a particular package, as Lone Wolf has done, so it mentions the absence of gcc.