Re: An X version of dselect for slink

1998-10-07 Thread Jamey Sharp
[EMAIL PROTECTED] 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



Re: An X version of dselect for slink

1998-10-03 Thread Joseph Carter
On Fri, Oct 02, 1998 at 05:09:18PM -0400, Steve Dunham wrote:
 For initial install on Intel, we could always use XF86_VGA16.  That
 should work on all systems.

People who have recycled Sparc monitors?  Even TEXT mode on those things is
an evil hack with svgatextmode!


pgpYkOcjfSEUt.pgp
Description: PGP signature


Re: An X version of dselect for slink

1998-10-03 Thread Philip Thiem
Jim Pick wrote:
 
 Tom Lees [EMAIL PROTECTED] writes:
 
  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
 
 Great!  Keep going...
 
 I really, really like the idea of having multiple front-ends for
 package selection that we can choose from.
 
 For some of the stuff I want to do, I'm going to need to be able to
 customize a front-end.  By having more than one front-end, we should
 end up with some good, well-defined interfaces.
 
 Cheers,
 
  - jIm
 

I agree very much with this we need multiple frontend.  In our quest
from a X11 let use never forget the text version.


 --
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

-- 
PENQUIN-LOVER-CODER ALERT:  [EMAIL PROTECTED]
   All windows user please exvacuate the building
 (So I can install a better OS on the comps)
Pass on the GAS get NASM instead.



Re: An X version of dselect for slink

1998-10-02 Thread John Lapeyre

On Fri, 2 Oct 1998, Enrique Zanardi wrote:

ezanarMoving X to the base disks (Auch!) and configuring X just after the first
ezanarreboot (hard task for a newbie). I'm not excited about that.

hard not just for the newbie !  I advocate, as usual, a sentence
in install.txt asking the user to only install preselected packages on the
first run through dselect. This would clear up many complaints.  Then
suggest installing X and running the Graphical-fe to dselect if the user
prefers an X interface.  The other option is to continue using terminal
front end but again ask them not to do too much at once.
A working GUI couldn't hurt in any case (unless it's buggy and
trashes systems !) 15 days of testing isn't much.
John


John Lapeyre [EMAIL PROTECTED]
Tucson,AZ http://www.physics.arizona.edu/~lapeyre



Re: An X version of dselect for slink

1998-10-02 Thread Steve Dunham
Tom Lees [EMAIL PROTECTED] writes:

 On Fri, Oct 02, 1998 at 03:18:13PM +0200, Hanno 'Rince' Wagner wrote:
  Hi,

  Enrique Zanardi schrieb am 02. Oktober 1998:

   Moving X to the base disks (Auch!) and configuring X just after the first
   reboot (hard task for a newbie). I'm not excited about that.

  Hmm - why not using the minimal X used for XF86Setup? It
  may me bad because it's the minimum - but it's X...

 Sounds good. When KGI is working nicely, we will have One True X Server
 (well, the choice between XF86_KGI and XF68_FBdev, but...). But until then,
 this will probably work.

As long as we have the choice to _not_ use the KGI X server.  (I don't
like it - last I checked, they translated keycodes-Unicode-keycodes
before handing them to the X server.)

For initial install on Intel, we could always use XF86_VGA16.  That
should work on all systems.


Steve
[EMAIL PROTECTED]