Re: An X version of dselect for slink
debian-devel-request@lists.debian.org wrote:
> Since it seems obvious that apt WON'T be finished (GUI bit I mean)
> before freeze of slink, I have started writing an X clone of the Dselect
> tool.
>
> Although to be ready by 16th will make it pretty much a hack, I think it
> is one worthy for this release (in much the same way as the
> preselections were earlier).
I have a very simple frontend to dselect in Tcl/Tk which simply replaces the
main menu of dselect... If anyone's interested, I could put it on my web
server, but probably both apt and gdselect are more advanced already.
> I will write it using GTK (I already have the basic framework done),
> development version 1.1 (for GtkCTrees, they are VERY useful for this).
>
> I have a couple of questions:-
>
> a) Does anyone else think this is a good idea?
Yup. (Otherwise I wouldn't have started my own similar project. <g>)
> b) How will this integrate with the installation
>
> Point b probably needs more expansion. What I mean is, if J Random Luser
> installs the basic system using the boot disks, it would be nice to
> start X, then this tool ASAP (basically, instead of Dselect). What needs
> to be done in terms of bootdisks and installation stuff to support this?
> (Presumably at least a question in the install "do you want to use a GUI
> install program or a TUI install program?").
I really like the idea of a full GUI install, but I have a use for running
Debian on 386s, so it'd be a pretty definite requirement (IMO) that dselect
stick around. (X wouldn't be pretty on a 386. <g>)
> Dselect's functionality is fairly simple - I believe I can have it
> duplicated and fully tested (enough for my scrutiny) under X by freeze
> time, after which others can test it.
Sounds good to me.
> Some more random dselect/dpkg questions for slink:
>
> Also, we need to deal with the dselect Install/Remove/Configure
> syndrome. We could easily put in my tool "Apply changes", which does all
> three (using same script interface). IMHO, we ought to switch completely
> to dpkg-mountable and apt (i.e. drop all existing default methods
> bar possibly dpkg-ftp and disks).
'apt-get dselect-upgrade' already does that. I'd go for dropping the Configure
and Remove options entirely from (g)dselect.
Also, apt supports mounted filesystems. It would be fairly simple to make it
be able to mount unmounted ones, I would think. (Just check /etc/mtab, and if
it's not there, mount it?) Therefore, I'd propose that this be purely a
frontend to apt.
Apt already has FTP support. Why keep using dpkg-ftp? And what is disks? Does
it handle multi-disk installs?
> What about multi-cd stuff? Should be integrated into mountable IMHO.
I think eveything ought to be integrated into apt.
> Can mountable handle an FS which isnt in /etc/fstab? If not,
> the bootdisks ought to as a bare minimum insert the installation
> medium (if CDROM) into /etc/fstab with options
> "noauto,noexec,nosuid,nodev,ro", and /floppy should be there too.
I don't see how mountable could handle anything not in /etc/fstab. But perhaps
the install routine should have an option for adding entries to /etc/fstab.
(Autodetection of which devices are what and should be mounted where would be
nearly impossible, I would think.)
-Jamey
____________________________________________________________________
Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
Reply to: