Dear maintainer,

The version of lcdproc currently in sid depends on two new packages:
- libconfig-model-lcdproc-perl (>= 2.040)
- libconfig-model-perl (>= 2.037)

Together, these are responsible for pulling in 53 PERL packages as dependencies
of lcdproc on my system. I feel that this is excessive, especially considering
the relatively minor functionality that these packages provide (namely, to
be able to upgrade the configuration file on package upgrades).

For example:

frost bootc # aptitude --simulate --without-recommends install lcdproc/sid
The following NEW packages will be installed:
  libalgorithm-c3-perl{a} libanyevent-perl{a} libb-hooks-endofscope-perl{a}
  libcarp-assert-more-perl{a} libcarp-assert-perl{a} libclass-c3-perl{a}
  libclass-data-inheritable-perl{a} libclass-load-perl{a}
  libclass-load-xs-perl{a} libclone-perl{a} libcommon-sense-perl{a}
  libconfig-model-lcdproc-perl{a} libconfig-model-perl{a}
  libdata-optlist-perl{a} libdevel-globaldestruction-perl{a}
  libdevel-stacktrace-perl{a} libev-perl{a} libeval-closure-perl{a}
  libexception-class-perl{a} libfile-homedir-perl{a} libfile-slurp-perl{a}
  libfile-which-perl{a} libhash-merge-perl{a} libjson-perl{a}
  liblist-moreutils-perl{a} liblog-log4perl-perl{a}
  libmodule-implementation-perl{a} libmodule-runtime-perl{a} libmoose-perl{a}
  libmouse-perl{a} libmousex-nativetraits-perl{a}
  libmousex-strictconstructor-perl{a} libmro-compat-perl{a}
  libnamespace-autoclean-perl{a} libnamespace-clean-perl{a}
  libpackage-deprecationmanager-perl{a} libpackage-stash-perl{a}
  libpackage-stash-xs-perl{a} libparams-classify-perl{a} libparams-util-perl{a}
  libparse-recdescent-perl{a} libpath-class-perl{a} libpod-pom-perl{a}
  libsub-exporter-perl{a} libsub-exporter-progressive-perl{a}
  libsub-identify-perl{a} libsub-install-perl{a} libsub-name-perl{a}
  libtask-weaken-perl{a} libtext-diff-perl{a} libtry-tiny-perl{a}
  libvariable-magic-perl{a} libyaml-perl{a}
The following packages will be upgraded:
  lcdproc
The following packages are RECOMMENDED but will NOT be installed:
  fuse lcdproc-extra-drivers libasync-interrupt-perl libclass-c3-xs-perl
  libclass-method-modifiers-perl libconfig-model-tkui-perl
  libdevel-lexalias-perl libdevel-partialdump-perl libfuse-perl libguard-perl
  libipc-shareable-perl libjson-xs-perl liblog-dispatch-perl
  libyaml-libyaml-perl libyaml-syck-perl
1 packages upgraded, 53 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,189 kB of archives. After unpacking 10.8 MB will be used.
Do you want to continue? [Y/n/?]
Would download/install/remove packages.

Can this functionality please be made optional at the very least?

Thanks,
Chris

Hello

ok. many packages are installed, but you don't need to worry about them. I
don't understand why you consider this is a problem.

It is. You will be asked whether to allow automatic upgrade or not.

All the best

I consider this a problem because it's a lot of packages that simply are
not going to be used on these systems. A number of drivers are split
into the lcdproc-extra-drivers package to avoid all users having to
install large parts of X11, I think it would be kind to users to allow
them not to install a large number of optional packages.

Could the config model packages be turned into a Recommends rather than
a Depends, so that they don't have to be installed at all?

It's really helpful to those of us who would like to maintain as minimal
a system as possible. For example, I'd like to use lcdproc on a firewall
system, and keeping the attack surface as small as possible is a common
goal for this type of system.

Thanks,
Chris

[ re-sent because I forgot to cc the BTS ]

Yes. A few MB of disks are wasted. Even on ARM system running on a SD card,
this is no longer a problem.

In this case, the large part of X11 are some X libraries which also weight a
few MB (no more than 10). This package split made sense a few years ago on
enbedded system where 32MB flash was a big deal.

Thanks to your mail, I've realised it's not worth the effort. I'll remove this
split the next time there's a problem around this hack.

It's also kind to user not to offer them a choice when the 2 alternatives have
no significant differences.

Technically, yes. But this dependency is injected by dh_cme_upgrade. This
would mean adding yet another option to the configuration file of
dh_cme_upgrade, adding documentation and explaining pro and cons of the
choice. This would make automatic config upgrade more complex for no real
added value.

Then, some documentation would need to be written for the end user so he can
make an informed decision, and recover from a wrong choice.

All this work for what ? saving a few MB not worth a cent on an SD card ?

None of these package will leave a running process. I don't see the relation
between the installed files and having a more vulnerable system.

All the best

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.
 

Le jeudi 30 avril 2015 18:00:39, vous avez écrit :

That's a valid point. I'll modify the message shown to user to specify where
to find the original configuration file.
libconfig-model-perl has changed.

Regarding the dependendies, I have to consider 2 scenario:
- if cme is recommended or suggested, people may get upgrade problem
  with lcdproc because they forgot to install cme (or removed it by mistake).
-  if cme is required, some people don't like having more packages installed.

I think the first scenario is a usability concern and harder to recover from.
The second problem is more subjective.

Hence cme will stay a required dependency.
is a conffile and cannot be modified by a script. That's why LCDd.conf landed in
/usr/share/doc .

All the best

-- 
Hello,
I'm Prof. Dr Diane, please a huge amount of payment was made into your
account. as soon as your respond is noted the payment confirmation
slip will immediately send to you.  please do not hesitate to reply as
soon as you receive this message. awaiting your urgent reply please.
Best regards
Prof. Dr Diane