[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel-package or kernel-source needs libncurses-devel

On 14-Apr-00, 16:48 (CDT), Josip Rodin <joy@cibalia.gkvk.hr> wrote: 
> On Fri, Apr 14, 2000 at 02:32:06PM -0500, Steve Greenland wrote:
> > > How high does that level have to be to be able to fetch a recommended
> > > package? apt-get (and related) already does everything one would ever want
> > > to do with packages, it just doesn't have a GUI but a CLI.
> > 
> > No, it doesn't -- it doesn't help with recommends and suggests; it
> > doesn't manage auto-uninstalls of packages that were installed only as
> > a result of meeting dependencies, etc., etc., etc. It's a command line
> > tool to retrieve and correctly install packages, ensuring that their
> > dependencies are met.
> But, to my knowledge, neither dselect nor capt nor aptitude do much more
> than apt-get, they don't manage auto-uninstalls of packages that were
> installed only as a result of meeting dependencies.

No, I was commenting on "everything one would ever want to do". There
are a lot of features that could be added to a higher level tool that
wouldn't be appropriate (I believe) for apt-get.

> By this reasoning, the sole purpose of those three programs would be to help
> with recommends and suggests, and of course do it with a nicer interface.

They also provide a nice browsing interface, sorting/searching, allow
one to make selections and then change your mind, etc. (Yes, to varying
degrees -- I'm generalizing.)

Exageration, but with a point: by your reasoning, we should get rid of
midnight commander and enhance ls.

I'm a big believer in layers of functionality.

> > The problem with adding autoinstall of recommends (or even an offer)
> > is that it is used as a tool by dselect et. al. Presumably, when I use
> > one of those tools, I've already chosen whether or not to install the
> > recommends and suggests. I do not want to be asked again, or have my
> > choices overriden.
> Several configuration directives to manage this whole behaviour would be in
> order, it seems.
> You can tell dpkg whether to keep, overwrite or ask on modified conffiles,
> for example, and it's all configurable (there is no config file, but that's
> on the TODO list :o). So if it's appropriate for dpkg to ask questions, I
> see no reason why apt-get wouldn't do the same.

I don't object ot apt-get asking questions (although it should
minimize...), but to it asking *the same* questions that dselect et. al.
have already (perhaps implicitly) asked and resolved. (I'll note that
dselect doesn't ask me about replacing conffiles, either.) The GUI/CUI
interfaces need to provide handling of Dep/Rec/Sug, so that the user can
make choices at the appropriate time. Duplicating that in apt-get is a

If you want a CLI that deals with Dep/Rec/Sug, it would seem better to
write a wrapper around apt-get...


Steve Greenland <stevegr@debian.org>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Reply to: