Dear Guillem, thank you for your detailed bug report. You are right, with the suggestion to create a new switch for cron, instead of creating a separate command. I hesitated to choose this method, but you convinced me.
I shall upload shortly a new release, with the possibility to launch `cron -N` instead of `cron_now`. Best regards, Georges. Guillem Jover a écrit : > 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 > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
