Re: Call for seconds: Policy modifications
Hi,
>>"Enrique" == Enrique Zanardi <ezanardi@ull.es> writes:
Enrique> But if we are going to talk about the content of the
Enrique> paragraph, I think we should discourage maintainers from
Enrique> prompting the user in the postinst.
Does not saying "only vital information" etc convey that
impression?
Enrique> One of our goals is to support unattended installations,
Enrique> isn't it?
Yes, but not at the cost of lost flexibility and stealth
upgrades. If we can manage unattended installation without dumbing
things down or losing functionality, fine.
Enrique> There are two things that prevent it: package configuration
Enrique> and displaying "vitally important" information.
And if unattended installatio means that vita information is
not displayed, I would do away woth unattended installation,
really. Flexibility, and solid upgrades, are important.
Enrique> For package configuration we have discussed many times how
Enrique> we would like to have a "configtool+database". Until that
Enrique> one is implemented, I guess anything the user must edit to
Enrique> make the package work should be edited in the postinst, as
Enrique> we want packages that work right after installation.
Correct.
Enrique> For the V.I.-info (not vitally important for the package to
Enrique> work),
If it is not vitally important, it need not be displayedo the
screen, and displaying non-vital information should be a bug.
Enrique> it may be mailed to the root account
No you don't. Not when I am installing/updating Debian on my
200 machine compute farm. Especially since we do not have unattended
installs anyway, and even then I would object to being spammed.
Enrique> or copied to root's home directory, or
User home directories, even roots, should be inviolate.
Enrique> ..., and a message added to dpkg "Read your mail ..." or
Enrique> "Read the file /root/README-foo for important installation
Enrique> information".
I disagree. Either we have the databse in place, or
equivalent, we should not make an half hearted attempt at this. We
should definitely not rush into solutions which are suboptimal. The
email solution may work, but only when we have a remote/mirror
installation process in place, which would take care not to spam.
Enrique> (It may make sense to add a flag for attended/unattended
Enrique> installations).
Only when we can actually support such a beast.
manoj
--
The two things that can get you into trouble quicker than anything
else are fast women and slow horses.
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: