anchor/tingle

A package updater for busy system administrators

tingle's Issues

check-updates-rpm fails to detect updates depending on system state and TERM environment

We've observed that tingle check will occasionally return a false negative, indicating that there are no pending updates, when in fact there are plenty. We eventually nailed this down to yum outputting Bold terminal codes, which breaks the awk regex in check-updates-rpm.

yum outputs bold text when the updated packages have already been downloaded but not installed, assuming that coloured output is enabled by default. This will occur if you check after a warm, or if the process is halted before/during the apply phase; rare but not implausible.

There are a few solutions to this that we can see:

1. Invoke as TERM=dumb tingle check
2. Modify the regex in check-updates-rpm to accept and ignore terminal control codes
3. Modify check-updates-rpm to invoke yum with --color=never
4. Modify bigpty to pass a suitable environment to subprocess.call, which would potentially affect/break/fix any other scripts that make use of bigpty

It's noted that this issue only affects interactive use. We've been using at to schedule our tingle runs and they work just fine because jobs appear to be run with TERM=dumb.

We have no particular preference for how/where the fix is made.

Making tingle portable

Hi,

I've been working on an OpenBSD driver for tingle using the new syspatch(8) utility due for release with OpenBSD 6.1.

Currently, tingle makes a few GNUish assumptions which mean that it cannot be correctly installed on a non-GNU system without patching every source file:

1. Each executable file starts with #!/bin/bash. Were this the only issue, it could be easily addressed by changing it to #!/usr/bin/env bash.
2. lib/tingle/common sets $PATH to /usr/sbin:/usr/bin:/sbin:/bin, meaning that systems which place bash in /usr/local/bin would not find it even with /usr/bin/env in the shebang.
3. Both the Makefile and the tingle source itself (when determining $TINGLE_PREFIX) assume that tingle is to be installed under /usr. This is not generally a correct assumption even on GNU systems; /usr is typically reserved for package-managed files, while a sysadmin who runs make install would expect the installation to end up under /usr/local.

The first two points can be easily resolved by removing the explicit $PATH and changing each shebang to #!/usr/bin/env bash. I do not see value in overriding whatever $PATH the sysadmin has provided.

The third is trickier, since scripts need to know how to find their libraries somehow, and bash does not provide a standard library include path. I can see three options here:

1. Provide a configure script and preprocess all of the sources during the build, which is marginally better than maintaining a separate patch for all of the sources on non-GNU platforms because it doesn't require regenerating every time the first few lines of a source file are changed.
2. Provide a configuration file in /etc which specifies where to find the system-wide tingle installation. This may be problematic because:
   • It requires parsing that configuration file in every executable, as knowing the system-wide location is necessary to load the common library routines.
   • While both GNU and OpenBSD generally place configuration in /etc for third-party software, this is not a portable assumption in general (e.g., FreeBSD uses /usr/local/etc).
3. Have each executable derive the location of its library from its own location ($0). This probably provides the best trade-off between portability and simplicity, but note that $0 may not always be a fully qualified path if the user did not invoke tingle using a fully qualified path. However, Darwin is the only system I am aware of where it is not, and tingle is unlikely to be used on Darwin systems.

I am happy to work on a solution and create a PR once I know what kind of solution might be accepted.