[Popcon-developers] Bug#808392: popularity-contest: ought to Recommends cron-daemon rather than specific cron implementations
2015-12-19 20:20 GMT+02:00 Bill Allombert <ballombe at debian.org>:
> fixed 808392 1.62
> quit
> On Sat, Dec 19, 2015 at 03:41:10PM +0200, Martin-?ric Racine wrote:
>> Package: popularity-contest
>> Version: 1.61
>> Severity: important
>>
>> popularity-contest explictly Recommends cron | fcron and Suggests anacron.
>>
>> It should instead:
>>
>> Recommends: cron | cron-daemon
>> Suggests: anacron | systemd-cron
>>
>> cron-daemon is the generic package name for any cron implementation.
>> Meanwhile, systemd-cron is an alternative package that provides
>> anachronic cron support.
>>
>> Making this change would allow the administrator to install the cron
>> implementation of their choice, instead of enforcing 'cron' package
>> installation.
>
> Hello,
> Historically a package implementing cron-daemon was not required to
> support cron.daily and cron.weekly, so it was not sufficient for
> popcon.
>
> This issue was fixed in debian-policy, and then in popcon 1.62, see bug
> #752504
In that case, we can probably close this bug.
> It is unclear whether systemd-cron anachronic cron support is sufficient
> for popcon usage.
It seems to work fine here.
> Recommends are advisory, so the sysadmin can still remove cron and
> install systemd-cron.
True, except that when APT is asked to --fix-policy, it will enforces
dependencies marked in Depends and Recommends. In stable, this means
pulling 'cron' since neither cron-daemon or systemd-cron is included
in popularity-contest's dependencies as valid alternatives:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Installing cron as Recommends of popularity-contest
Correcting dependencies... Done
The following extra packages will be installed:
cron
Suggested packages:
checksecurity
The following packages will be REMOVED:
systemd-cron*
The following NEW packages will be installed:
cron
> So I do not think this issue is serious enough to justify a stable
> update.
This is entirely up to the maintainer. At least, it's finally fixed in
unstable now.
Martin-?ric
Reply to: