Re: Progeny Linux Systems Announces Progeny Debian Beta One
On Fri, Nov 03, 2000 at 01:40:38PM -0500, Buddha Buck wrote:
[snip]
>
> I think the main problem is that dselect treats recommends as overideable
> depends, and treats an unmet recommendation as if it were a conflict.
>
> I wouldn't mind seeing behavior from apt-get something like so:
>
> ------------------
> # apt-get --install foo
> Package 'foo' depends on the following uninstalled packages:
> bar baz bat
> These packages will be installed automatically
>
> Package 'bar' conflicts with the following installed package:
> bar-old
> This package will be removed automatically
>
> The following package is recommended for this installation:
> quux
> Install this package [Y/n] ? n
>
> The following packages are suggested for this installation:
> fred phlegm
> Install these packages [Y/n] ? y
>
> The following packages will be INSTALLED:
> foo bar baz bat fred phlegm
> The following package will be REMOVED:
> bar-old
> Is this OK [Y/n]? Y
> ----------------
>
> and so on. If a user then chose to install another package that did -not-
> recommend quux, he/she would not be asked about installing quux.
>
> My feeling is that apt-get should work incrementally, not looking at global
> state unless specifically asked.
>
> It would also be nice to have command-line options that could be used to
> fine-tune the above process: --show-recommends/--show-suggests would have
> the above behavior, --no-recommends/--no-suggests would assume "no" to
> installing recommended or suggested packages and not ask,
> --yes-recommends/--yes-suggests would assume "yes" to installing
> recommended or suggested packages and not ask.
>
> I don't mind being asked repeatedly if I want to install quux everytime I
> install/reinstall a package that recommends quux. I'm uncertain about
> being asked repeatedly when I upgrade, though.
>
I'd say something to cover that point could be to add it to debconf? I thought
that it's purpose is to save settings that have to be processed by the installer
every time it get's invoked. Of course that would end up in having one or
several fields that have all packages in common (in the debconf database).
Is this a good a way to approach that problem? I am really interested in
other opinions about it.
--
kind regards,
Michael Moerz
Reply to: