Re: Proposal: dump dselect for console-apt
On Sat, Oct 16, 1999 at 12:34:45PM -0400, Adam Di Carlo wrote:
> Matt Porter <mmporter@home.com> writes:
>
> > My recommendation only applies to what is launched after the task
> > management GUI. In non-expert mode, I don't think anything should be
> > launched since it just complicates matters. The new user will just select
> > "Home Computer" and when it is finished it will kick them out to the login
> > prompt.
>
> I agree with this sentiment. A large flaw in the old system was that
> the user had to pick selections, and *then* go into dselect, just do
> 'configure', 'update', and 'install', avoiding 'select'. Ick!
Ok, at least we are in agreement on the important part.
> > The advanced user will select an option that will kick them out
> > to console-apt so they can search around and add a few more individual
> > packages to their liking.
>
> Or dselect .... This talk of console-apt right now is pure vapor,
> isn't it? I'm interested in what can be done in the next 5 weeks, not
> next 5 months.
Well, capt is not vapor. It exists, and is usable now. There are some
bugs, but with some prodding I'm sure it could be made suitable in ~3-5
weeks. We just need to catch somebody's interest who wants to bang on it
a bit and fix things.
> Anyhow, I wonder if it would be possible to ship dselect in base
> already configured to use the apt acquisition method....
Ok, I would like this too. If in expert mode, the system kicked out to
dselect defaulting to apt acq, then I think I would survive. :)
Unfortunately, it has a lot of bugs that make it very difficult on some
systems.
For example, if on a serial console system. kbd and console-tools
packages are removed during final installation. Start up dselect at the
end of the install and it nsists on reselecting those packages just
because they are in base. They spit all kinds of warning/errors if they
are installed since loadkeys/dumpkeys are in postinst and need a VT to run.
Another one I see is that a whole bunch of package seem to be selected so
we get in this insane perl4 perl4-debug dependency conflict that can't be
resolved. An experienced user will remove the packages, but a new user
who just wants to add a couple packages that he knows by name will be
completely lost.
> > These capablities should be moved to apt since it is the next gen. I'd
> > imagine by the next (post potato) release dselect should be gone.
>
> Maybe, maybe not. In the context of the boot-floppies group, our job
> is to do the best we can with what the distro is giving us. If it
> gives us a rockin' console-apt which everyone agrees is better, then
> we would replace dselect with it (if it was small enuf).
I'll go out on a limb and suggest that perhaps it should be a two way road
here. If dselect isn't exactly what is wanted for the installation process
then we need to file wishlists against it (yes, I will do more
than talk about this with respect to capt). We can also push these
discussions about the shortcomings of tools we rely on for boot-floppies
to debian-devel to get a broader audience and perhaps some interested
developer who can spend some time on improving dselect or capt.
If we just relied on what was given to us, we be stuck with having the
full perl5.005 instead of just perl5.005-base in base. Instead we
communicated what we needed to the maintainers.
That said, since we are still looking at a Nov. 1 freeze, I guess it is
sufficient to have the standard/expert installation option going into the
task GUI and kick out to dselect configured for APT if in expert mode.
The dselect problems I mentioned (and others) can be addressed after the
freeze as bugs fixing.
--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.
Reply to: