Bug#743870: Re: Bug#743870: Excessive dependencies required on upgrade
[ re-sent because I forgot to cc the BTS ] On Thursday 10 April 2014 13:22:45 you wrote: > I consider this a problem because it's a lot of packages that simply are > not going to be used on these systems. Yes. A few MB of disks are wasted. Even on ARM system running on a SD card, this is no longer a problem. > A number of drivers are split > into the lcdproc-extra-drivers package to avoid all users having to > install large parts of X11, 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. > I think it would be kind to users to allow > them not to install a large number of optional packages. It's also kind to user not to offer them a choice when the 2 alternatives have no significant differences. > >> Can this functionality please be made optional at the very least? > > > > It is. You will be asked whether to allow automatic upgrade or not. > > 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? 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 ? > 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. 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 signature.asc Description: This is a digitally signed message part.
Bug#743870: Excessive dependencies required on upgrade
On 09/04/14 19:14, Dominique Dumont wrote: > Hello > > On Monday 07 April 2014 16:44:47 you wrote: >> 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). > > 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. 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. >> Can this functionality please be made optional at the very least? > > It is. You will be asked whether to allow automatic upgrade or not. 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 -- Chris Boot deb...@bootc.net GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743870: Excessive dependencies required on upgrade
Hello On Monday 07 April 2014 16:44:47 you wrote: > 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). 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. > Can this functionality please be made optional at the very least? It is. You will be asked whether to allow automatic upgrade or not. All the best signature.asc Description: This is a digitally signed message part.
Bug#743870: Excessive dependencies required on upgrade
Package: lcdproc Version: 0.5.6-1 Severity: normal 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 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.13-1-486 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lcdproc depends on: ii libc62.18-4 ii libncurses5 5.9+20140118-1 ii libtinfo55.9+20140118-1 ii lsb-base 4.1+Debian12 Versions of packages lcdproc recommends: pn lcdproc-extra-drivers lcdproc suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org