glsnake is the interactive version of the famous glsnake xscreensaver hack. This is a simple ebuild for a simple program. It requires GLUT to compile and run. It installs only one binary plus the documentation. The build system is scons, but, as the source contains only one file, I think it might be a good idea to "hardcode" the compile command (which will avoid the scons dependency). I've added such command as comments. As the xscreensaver version, this ebuild also patches some offensive glsnake names. (see bug 46256, or look at xscreensaver patches) I've tested this ebuild on amd64, and I'm pretty sure it will work on x86. BUT I know this ebuild has a file collision with xscreensaver package. Both try to install glsnake.6 manpage. I guess the solution is to rename one of the manpages (probably this one). If that's the case, probably rename the glsnake executable too. I'm expecting someone else to have a better solution, or to at least suggest a name.
Created attachment 167210 [details] glsnake-0.9.1.ebuild I'm suggesting the x11-misc category, which is the same as xscreensaver package.
Created attachment 167212 [details] glsnake-0.9.1-offensive.patch This patch was copied directly from xscreensaver.
Just a few comments: -you can use ${PN} in SRC_URI -dobin should get a "|| die" -if you want to avoid scons, you should have a look at the toolchain-funcs.eclass to avoid hardcoding things So far from my side
Created attachment 167229 [details] glsnake-0.9.1.ebuild (In reply to comment #3) > -you can use ${PN} in SRC_URI Hum... True. Well, we can then use ${PN} everywhere where we use the string glsnake. But, will this really improve anything? In my humble opinion, it doesn't. I think it makes sense for sourceforge URLs, for example, but for this one, I don't see any reason to use ${PN}. Just my 2 cents, of course feel free to use ${PN} anyway. > -dobin should get a "|| die" Ok, missed that. Fixed that. > -if you want to avoid scons, you should have a look at the > toolchain-funcs.eclass to avoid hardcoding things You're right. I'm attaching an updated ebuild without scons dependency and with fixed src_compile/src_install. I've not replaced "glsnake" by "${PN}", maybe it could make sense to do it in src_compile and src_install.
(In reply to comment #4) > Created an attachment (id=167229) [edit] > glsnake-0.9.1.ebuild -Why do you set RESTRICT="test"? -You could set DEPEND="virtual/glut" and remove RDEPEND. Without a RDEPEND the package manager assumes RDEPEND="${DEPEND}". > > (In reply to comment #3) > > -you can use ${PN} in SRC_URI > > Hum... True. Well, we can then use ${PN} everywhere where we use the string > glsnake. But, will this really improve anything? In my humble opinion, it > doesn't. > > I think it makes sense for sourceforge URLs, for example, but for this one, I > don't see any reason to use ${PN}. Just my 2 cents, of course feel free to use > ${PN} anyway. Why only for sf urls? It does not happen often, but if a package gets renamed, the ebuild could just be renamed. Without ${PN}, you have to search the ebuild and change every entry of the name (In principle the same reason as why you should not hardcode the version, but use ${PV}).
(In reply to comment #5) > -Why do you set RESTRICT="test"? Because this package has no tests, so I thought it was a good idea to tell portage to don't even try testing it. If it wasn't a good idea, then sorry, and please tell me why, so I won't repeat this in future. > -You could set DEPEND="virtual/glut" and remove RDEPEND. Without a RDEPEND the > package manager assumes RDEPEND="${DEPEND}". Ok. <offtopic>(but then I remember "The Zen of Python": Explicit is better than implicit.)</offtopic> > Why only for sf urls? > It does not happen often, but if a package gets renamed, the ebuild could just > be renamed. Without ${PN}, you have to search the ebuild and change every entry > of the name (In principle the same reason as why you should not hardcode the > version, but use ${PV}). I guess that, if the package gets renamed, probably this URL will remain the same. Or, the URL will change a lot more than just the package name. I feel that, if a package (or this package) gets renamed, we will need to change more than just renaming the ebuild. Also, running a simple "s/glsnake/something/g" is not very difficult. But, anyway, feel free to use ${PN} then. But should it be also used in src_compile/src_install?
(In reply to comment #6) > (In reply to comment #5) > > -Why do you set RESTRICT="test"? > > Because this package has no tests, so I thought it was a good idea to tell > portage to don't even try testing it. If it wasn't a good idea, then sorry, and > please tell me why, so I won't repeat this in future. It is simple: If there is no test, portage/make will see it and move on. It is the same as e.g. for missing configure or makefile. RESTRICT="test" would only be usefull if there exists a testcase, but it is borked and would always fail. > > > -You could set DEPEND="virtual/glut" and remove RDEPEND. Without a RDEPEND the > > package manager assumes RDEPEND="${DEPEND}". > > Ok. <offtopic>(but then I remember "The Zen of Python": Explicit is better than > implicit.)</offtopic> There is some rule for ebuilds: Make them simple and readable. So e.g. if you have nothing to patch, you can just drop the complete src_unpack function. Those things are defined as default, so you can count on them. > > > Why only for sf urls? > > It does not happen often, but if a package gets renamed, the ebuild could just > > be renamed. Without ${PN}, you have to search the ebuild and change every entry > > of the name (In principle the same reason as why you should not hardcode the > > version, but use ${PV}). > > I guess that, if the package gets renamed, probably this URL will remain the > same. Or, the URL will change a lot more than just the package name. I feel > that, if a package (or this package) gets renamed, we will need to change more > than just renaming the ebuild. > Also, running a simple "s/glsnake/something/g" is not very difficult. > But, anyway, feel free to use ${PN} then. But should it be also used in > src_compile/src_install? > I am just giving out some hints for improved ebuild writing, i am not able nor do i plan to maintain it in the main tree.
Software moved GitHub for hosting: https://github.com/jaqx0r/glsnake Latest activity 2020-12-20. No packaged releases, so it would need pulling based on commit or manually packaged, published, and pulled into the distfile mirrors.
