Ola Lundqvist <[EMAIL PROTECTED]> (21/04/2006): > On Fri, Apr 21, 2006 at 07:35:01PM +0200, Thomas Huriaux wrote: > > Ola Lundqvist <[EMAIL PROTECTED]> (21/04/2006): > > > The usefulness of this package is that the admin will know about > > > this _during_ the installation. > > > > > > I still do not understand why you have a problem with this. > > > > Because installation is not the place to care about this. As I've said, > > the purpose of a package should be documented on places such as package > > description, project website, ..., the use of a package should be > > documented in manpages, README files, etc. Keep the things where they > > belong. > > But this package is intended for people that are not that used to Debian > and security hardening. They probably do not even know about the README.Debian > files anyway.
Do you really think that people not used to Debian and security hardening will understand that the notes they read during the installation process are instructions to apply after the installation? > > Just imagine that every package displays debconf notes such as your > > package does (i.e. notes that are not related with the package > > configuration). I really think that Debian would be unconfigurable, as > > every package would stop the installation procedure many times > > (especially true for harden/welcome, even if it is also true for the > > other notes). > > I agree in general but I still think that these notes are valid to print. > > > Another problem that I see with this: during the installation procedure, > > I usually only want to configure the newly installed packages. In this > > case, I'm installing the harden suite and plenty of other packages. As > > I've seen that the Debconf notes were not related with the configuration, > > I just read them but took no action immediatly, as it is better to finish > > the full installation before reconfiguring other packages. Now that my > > installation is finished, I want to make my system secure. > > I don't think that dpkg-reconfigure harden-servers is the intuitive > > way to find the instructions (this is especially true for the > > harden-servers/vncserver and harden-servers/inetd notes). > > We can of course add the notes to the README.Debian file as well as the > debconf output. > > > Finally, I would accept some notes being displayed during the installation > > procedure, but only before being prompted by apt/aptitude if I accept to > > remove packages that conflict with harden* (in the case of > > harden-servers/plaintext and harden-clients/plaintext). This is > > unfortunately not possible, AFAIK. With the current conception of the > > package, these notes are displayed too late to be useful during the > > installation procedure. > > What? The notes are not for you to remove packages but to make sure that > you use try to configure your system for encryption. Then it is worst than I thought. If these notes are not even made to explain what's happening during the installation process, then they really should be removed. > > Conclusion: If you want to keep the current philosophy of the package > > without bothering users with pointless notes, you should take the > > following actions: > > * remove harden/welcome (or move it to a README.Debian file) > It is already with priority low output, so I do not really agree. Even with a low priority, once again, imagine that every package displays a note with "Hello, you are using the foobar package. You can find more documentation blablabla...". It would simply make the low priority unused by users. > > * remove harden-*/plaintext and emphasize (if needed) the package > > description about the conflicts > But they are not for describing the conflicts. See above. > > * provide documentations such as README, manpage, ... for > > harden-servers/inetd and harden-servers/vncserver (and of course > > remove those notes) > > No I will not do this last point, unless inetd have changed their > defaults of course. Still the same difference of opinion, i.e. something like that has no added value during the package configuration process. I'm afraid our main disagreement is the distinction I made between installation/configuration of a package and use of a package. It seems for me that you consider you're using a package as soon as you start to install it. If I'm right with this last statement, then I will change my argumentation :-) Sorry to be so insistent for the removal of these debconf templates, but one of my main activities within Debian is debconf-related QA and I'm still convinced that you are using debconf where you should not. That's why I really would like to see this issue fixed :-) Cheers, -- Thomas Huriaux
signature.asc
Description: Digital signature
