[Hamara-devel] packages to be installed in stretch - need to think of something similar for hamara

[shirish]

Hi all,
This has been in mind for quite sometime now (ok, since the time I saw 
the thread few weeks ago) but as Vik and soon Raju would also be 
involved in this (and probably me as well once I get things set at my 
end.) this is something that we need to think for hamara as well.

See https://lists.debian.org/debian-devel/2015/05/msg00089.html

It's is a bit of long read and a longer thread but it does tell that we 
needn't be married to the values that Debian gives to each of the 
packages. From the first message it is clear that the target in question 
is a container but even without that it does tell that we can move the 
targets up and down in priority for our convenience.

  This does mean that we would need to know some of the packages more 
intimately than we do for now (especially the ones which have the 
tag/Priorty as 'Essential' , 'Standard' , metapackages - the works.

For instance, rsyslogd is the main log that Debian uses but not all 
packages use rsyslogd, should we use that or use something else. For 
cron, there is anacron which arguably provides a better service or 
having a 'cron-daemon' as shared in the same thread

https://lists.debian.org/debian-devel/2015/05/msg00107.html

In fact, I had private conversations wherein systemd-cron would be more 
useful if the crontab functionality could be taken out of cron itself 
and be a separate library which will provide the service to 
systemd-cron. The reason that such conversations will not spill over at 
least now to the public domain because anything to do with systemd is 
fully flame-war material.

That is the reason that Michael Biebl who's an awesome prolific GNOME 
and systemd uploader and maintainer had to resign for sometime after 
systemd came into Debian. I really don't want to get into that history 
as it's pretty convulated and had too many actors and too much bad blood 
between people (and some of it still remains and guess will remain for 
quite sometime.)

We could very well use systemd-cron *if* we are able to get all the unit 
service files for all the packages and have their cron jobs defined in 
the service files itself.

See :-

[$] aptitude show systemd-cron
 

Package: systemd-cron
State: not installed
Version: 1.3.1+ds1-2
Priority: extra
Section: admin
Maintainer: Debian Systemd Maintainers 
<pkg-systemd-maintainers at lists.alioth.debian.org>
Architecture: all
Uncompressed Size: 137 k
Depends: init-system-helpers (>= 1.18~), systemd-sysv (>= 212), 
python:any (>= 2.7~), python
Conflicts: anacron, cron-daemon
Replaces: anacron, cron
Provides: anacron, cron-daemon
Description: systemd units to provide minimal cron daemon functionality
  Provides systemd units to run cron jobs in /etc/cron.hourly cron.daily 
cron.weekly and cron.monthly directories, without having cron or anacron
  installed. It also dynamically translate /etc/crontab, /etc/cron.d/* 
and user cronjobs in systemd units.
Homepage: https://github.com/systemd-cron/systemd-cron

Once we have the initial .iso I would see if I can get Michael to share 
the script which checks if all the packages have systemd unit service 
files (it probably is public but probably poorly documented somewhere in 
the vast debian.org infrastructure) and have something similar to the 
diaspbar which Praveen had shared at 
https://people.debian.org/~praveen/diasbar/ with modifications that we 
need/want.

Look forward to feedback.
-- 
Regards,
Shirish Agarwal,
Community Lead,
Hamaralinux.org