Source: cron
Source-Version: 3.0pl1-173
Severity: normal
Hi!
While reading the changelog [C] during an upgrade I noticed a suspicious
entry, and when I went checking to confirm it noticed multiple issues
with the cron_now feature:
* There's a hardcoded libselinux1 dependency in the binary stanza
in debian/control, which is wrong, as that should be generated
automatically by dpkg-shlibdeps when needed (would make part of
the gratuitous non-linux restriction unnecessary).
* The implementation and scaffolding for this cron_new features seems
overly complicated and not ideal:
- It uses a python script to "patch" the original cron.c to create
a new command. A better, simpler and more future-proof way would
have been to simply patch cron.c directly.
- Builds this new command ignoring all system dpkg-buildflags, and
hard-codes optional features already handled as such in
debian/rules and the upstream build system. Making the package
gratuitously non-portable (unconditional use of pam, selinux and
audit).
- The current hardcoding includes maintainer specific system paths
such as «/home/georgesk/developpement/cron/collab/cron».
- Nit: could use execute_after_<dh_command> to avoid calling the
overridden command. Or simply use stuff like debian/clean
instead of any dh_auto_clean override at all. But this is all
completely unnecessary if there is no cron_new, or if its build
is handled by the upstream build system.
* There is a new interface (the cron_new program), instead of say
adding a new option flag, which complicates the build system and
duplicates the functionality in two programs. Is this public new
interface in the form of a new program really justified (instead
of simply adding a flag)?
(If you'd insist with this new cron_now interface, then this could
be done in a better way by patching the original code in cron.c
within «#ifdef» blocks or similar, and then modifying the upstream
build system for this new target, taking into account build flags
and variable features).
[C] BTW, please describe what the actual changes do, writing something
like “applied one change proposed by Helge Kreutzmann (thanks!).”
is not very helpful and requires going to the bug report.
Thanks,
Guillem
