I would like to second this bug report. I also find the perl dependencies required for "cme" are excessive and should be moved from Depends to Recommends at the very least in lcdproc. I don't see any concern as above with attack surface or the minimal disk space, but I do think that cme and it's dependencies are incorrectly required as part of lcdproc when they are certainly not required to utilize lcdproc in any way or build it from the upstream source tarball. I'm also concerned about the removal of /etc/LCDd.conf as a Debian conffile from the lcdproc package. I understand that it is against Debian policy to have a maintainer script modify a dpkg managed conffile (which is the obvious goal of cme), but should the user not choose not to use cme to manage the configuration via the install prompt in apt/dpkg, the only copy of the needed configuration in order to get lcdproc to do anything useful is buried down in /usr/share/doc/lcdproc/LCDd.conf.gz, and no indication of this fact is given to the end user at install time. To the naive user who has never installed lcdproc before, they would not know to look for this file there instead of the Debian standard location of /etc/, as was previously managed by dpkg. As a solution to both of these issues, it seems that it would make a lot of sense to separately package "cme" and set "libconfig-model-lcdproc-perl" only as a Recommends or ideally, imo, a Suggests instead of Depends for lcdproc. Obvously, you would then set "cme" as a Depends on "libconfig-model-lcdproc-perl", so that you could actually make use of the suggested package. You would also need to restore /etc/LCDd.conf as a dpkg conffile, so that it retains all of the benefits of being managed by dpkg. Then, at install time for lcdproc, if libconfig-model-lcdproc-perl is (or is going to be) installed, prompt the user if they would like to use cme to manage the configuration. If they select yes, inform them that after the installation is complete, to modify the configuration by running "cme edit lcdproc" (or whatever command) and let cme overwrite the default config file in /etc/LCDd.conf. If they select "no" to management, then the correct file is already in /etc/LCDd.conf and the user can manage the file in the traditional manner. There is no certainly no Debian restriction that I know of on having an external program modify a dpkg-tagged conffile after the dpkg transaction is complete, only that it not be done at install time. Samba’s SWAT works (worked?) in this manner quite successfully, and it seems would be a good model to emulate. I'm sure I'm missing some fine nuance of Debian packaging with the above idea, but that would be the basic workflow for the package installation. This would solve the problem of "too many dependencies" as reported in this bug report as well as giving the users the option to not use cme if they should so desire.
-- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
