>>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.
>> - 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.
>>The second problem is more subjective.
>>Hence cme will stay a required dependency.
It's a bit disingenuous to say, "without cme installed, the user might have install/upgrade problems with lcdproc." The lcdproc for wheezy did not have cme as a dependency, nor did the version for squeeze. It installed/upgraded just fine between both branches of Debian with no issues, even with all of the proper conffiles set in /etc. If I wanted to build lcdproc from the upstream tarball, I'm pretty sure libconfig-model-lcdproc-perl isn't going to be needed to do a make; make install and get a working binary from the source tree.
CME is, as a gross oversimplification, not much more than a semi-automated text editor. There is no more merit in setting CME as a dependancy to lcdproc than there is to setting any other text editor as a dependency in its place. Let's set "emacs" (with it's 41 sub-dependencies and a custom lcdproc macro) as a dependancy to lcdproc, and tell the user at install time, "Well, you don't really have a choice about installing emacs or not, because that's what the package Requires (even though it doesn't actually need it to function)", and then later give them a prompt that says, "*If* you "want" to use emacs (which I forcefully installed for you) to edit the config file, I'll be nice and put the config file in the right place and even prepopulate some of the data you need in there, but otherwise good luck on configuring the package on your own." That's pretty much the situation given to the user with the forced relationship between cme and lcdproc.
>>Can't have both. This is decided at packaging time: any file installed in /etc/
>>is a conffile and cannot be modified by a script. That's why LCDd.conf landed in
>>/usr/share/doc.
>>is a conffile and cannot be modified by a script. That's why LCDd.conf landed in
>>/usr/share/doc.
The Debian Policy states that a package should not modify a dpkg-handled conffile in its *maintainer scripts*, which if I'm not mistaken is exactly what cme is (would be) doing. It says nothing that I'm aware of about editing a conffile after the package is installed.
So the current solution to this gotcha is, "I'll just remove the primary configuration file from the package as a conffile so that I don't break the Debian rules, and give the user a "choice" to use cme and "fix" the missing config file with my tool so that it ends up in the right place. However, should they opt not to use it, I'm going to leave the package in a half-installed state, as the required files needed to run it are now missing from /etc." I'm pretty sure that qualifies as a bigger usability concern than the user having to do a rare "diff /etc/LCDd.conf /etc/LCDd.conf.dpkg-dist" after an upgrade if the daemon wont start with the old config file.
How about instead, offer cme as a standalone package and Suggest to the user that they use it in parallel with lcdproc instead of the heavy-handed and somewhat broken paradigm of forcing it "in-line" to the package and thereby breaking established protocol with regard to the handling of config files? Let the user decide to use it or not with lcdproc (or any other package for that matter.) Do you feel that cme does not provide enough benefit and would not be used by the users if it were not forced as a default in a Debian package? Yes, there is the menu selection of "use cme? yes/no", but when the options are "use cme" or "enjoy your reduced functionality", that's not much of a choice, now is it?
Sent: Friday, May 01, 2015 at 8:57 AM
From: "Dominique Dumont" <d...@debian.org>
To: "Robert Cooke" <rob.co...@gmx.com>, 743...@bugs.debian.org
Subject: Re: Bug#743870: 743870 lcdproc bug
From: "Dominique Dumont" <d...@debian.org>
To: "Robert Cooke" <rob.co...@gmx.com>, 743...@bugs.debian.org
Subject: Re: Bug#743870: 743870 lcdproc bug
Le jeudi 30 avril 2015 18:00:39, vous avez écrit :
> 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.
That's a valid point. I'll modify the message shown to user to specify where
to find the original configuration file.
> 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.
I also need to update lcdproc dependency list as the layout of cme and
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.
> 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.
Can't have both. This is decided at packaging time: any file installed in /etc/
is a conffile and cannot be modified by a script. That's why LCDd.conf landed in
/usr/share/doc .
All the best
--
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
> 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.
That's a valid point. I'll modify the message shown to user to specify where
to find the original configuration file.
> 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.
I also need to update lcdproc dependency list as the layout of cme and
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.
> 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.
Can't have both. This is decided at packaging time: any file installed in /etc/
is a conffile and cannot be modified by a script. That's why LCDd.conf landed in
/usr/share/doc .
All the best
--
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
