Arch Linux User Repository

I consider files outside of PKGBUILD to be hidden. It’s frustrating look through a .spec or PKGBUILD to run across a patch that is nowhere to be found. All the lofty claims that AUR helpers are secure because they let you read the PKGBUILD don’t count for much if the nefarious patches are hidden outside of it. I bring anything into the PKGBUILD that doesn’t make things more messy. I use patch when I need to know if patched code is changed. sbin errors will be detected during install so there’s no need to know whether it it applies or not. sed will adapt the changes to any context and position. patch will need to be redone every so often. patch grows with the number of fixes. A single sed handles any number of fixes.

The only reason -j isn’t breaking more PKGBUILDs is because noone uses -j. I know they don’t because if they did they would be demanding a switch on make to nice it. I can take -j1 off of the make but -j1 is very necessary on make install. You do hardcode -j into PKGBUILD when you know the makefile is broken. That’s why I comment the reason for -j1.

Sourceforge is down most of the time. Using Sourceforge as a download source results in a constant stream of complaints. I can change the upstream URL back but I avoid downloading from Sourceforge. Seems to me that SF developers are heading for the exits and I can help with that by publishing github instead of Sourceforge. When doing such a change I ensure the new files are the same as old and that there is reason to believe the developer is the same or just as good.

100.000% of all shell scripts should have set -u running including those that don’t have variables. I’ll keep turning it on until the Arch devs catch on and turn it on in makepkg for everyone. Not using set -u results in garbage shell code. It seems unimportant for this package but I’ve standardized on it in all packages so it’s there in the big packages where it is essential. It also helps catch bugs from previous packagers. Once in there’s no reason to take them out.

_verwatch is used by my AUR helper git-aurcheck to check for updates. I recognized right away that waiting for users to request updates results in packages that are years out of date and after about 10 packages manually checking for updates becomes impractical. I also knew that each package would have different rules. All current upstream update management scripts and systems are no good so I added the functionality into my utility and it works wonderfully. _vercheck customizes update checking for each package. Aspects of it need to be incorporated into the AUR servers with plenty of server based improvements. I used to parse the github release page directly then I found the RSS page which works much better. The comment is my reminder that the package is using the new RSS feed.

I keep the old source and url as a comment so others reading the PKGBUILD know about the other options. It’s also easy to switch back. I try to make my PKBUILD useful to everyone in every distro and future packagers, not just a few bumbling yaourt users.

git-aurcheck tells me what files need to be added and removed and even provides the commands for copy pasta. .gitignore and git add * is garbage technology by comparison.

Always running configure or cmake breaks makepkg -ef and makes a mess, not a clean build. I tried placing them in prepare() but that turns makepkg -sCo into a nightmare. Since makepkg won’t provide us a configure() this is the only way I’ve found to make PKGBUILD work properly for developers. Use makepkg -C for a clean build. makepkg is highly developer friendly but not when most PKGBUILD are incorrectly written.

My shell scripting follows extremely strict formatting standards. Almost always using quotes and ${} are two of them. For the reason let’s look at two variables, $FOO and $FOOBAR. I’d like to replace all occurrences of $FOO with $BAZ but you can see that this will result in $FOOBAR - > $BAZBAR which I don’t want. You might think that [x]WholeWordsOnly will fix that but all editors consider $ a word break character. This sucks in BASIC too. The solution is to use ${FOO} and ${FOOBAR} and now search and replace in any editor works properly, at least until we use ${FOO//bar/baz}.

I didn’t replace your PKGBUILD so you’re still a contributor. I maintain lots of PKGBUILD and many are huge so I apply the same methods to all of them with automated tools, even to small PKGBUILD like this one where they all seem unnecessary.

Hi, thanks for adopting the package. I noticed a few odd things in the last change, though:

• Why replace the patch by sed? A patch errors out if it fails to apply, whereas sed just silently fails, and so one has no way of knowing whether the change was actually applied correctly.
• What's the point of -j1? "No speed benefit" is totally not an argument for hardcoding and limiting the compilation to a single core. Unless compiling with multiple cores causes issues for a particular package, NEVER hardcode -j into PKGBUILDs.
• Why change the upstream URL from the project website to the Github project page? Also, according to https://github.com/rocasa/ttylog/issues/10, upstream is still on Sourceforge (although I agree it's a bit irritating).
• What's the point of all the set -u? Not that that's a bad thing per se, but it's a bit irritating that you'd explicitly need that in this particular package.
• What's the point of _verwatch? I don't see it used anywhere. Also, what's the purpose of an RSS feed in a PKGBUILD anyway?
• Why keep around (old) stuff as comments? Use git to your advantage :-)
• Speaking of git, why remove the gitignore?
• I can see why you may want to check for the existence of the build directory, but that could more easily be done with mkdir -p. Not sure about whether running cmake only in one of the cases makes sense, but that's probably just an opinion (I prefer a clean build in all cases).
• What's the point of {} around the variables? They don't serve any purpose here.

It looks like you have simply replaced the entire PKGBUILD with another one you had lying around, so I guess you could remove me as "Contributor" - I would not mind.

By the way, I hadn't got around to reporting the sbin issue to upstream, so you could still do that someday. ttylog is perfectly able to run without being root, so even for systems that have bin and sbin separate, it makes no sense - and it is also not statically linked (the original purpose of sbin), so that argument wouldn't hold either. Upstream may still reject it on the base of "legacy reasons" or whatnot, so don't push too hard :-)