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

Re: More Debian v1.2 things...



On Tue, 22 Oct 1996, Philippe Troin wrote:

> On Mon, 21 Oct 1996 18:21:43 EDT Shaya Potter (spotter@itd.nrl.navy.mi
> l) wrote:
> 
> > i.e. lets make dselect easier to use.  Maybe their should be an X based 
> > version of it, along the lines of the make -xconfig for the linux kernel.  
> > It might not be simpler to use, but people are more comfortable dealing 
> > with a graphical system (just look at the mac, or ms windows).  
> 
> I could try to have a look a that. I've been thinking of a Tk
> interface to dpkg for a while now. What do you think about it (making
> no promises on delivery date :-) ?

sounds like a great idea.

here's something to be careful of: what happens when xdm is upgraded?
AFAIK, when xdm is upgraded, it is first stopped, then restarted...any X
sessions will be killed.

maybe do a check on xdm versions, and print a message saying something
like:

    tk-dselect has detected that xdm is about to be upgraded.

    Unfortunately, upgrading xdm will terminate any active X servers
    (including the currently running session), so tk-dselect cannot
    perform this upgrade until xdm is upgraded.

    please exit X and upgrade xdm by hand.
    
    do the following:
        logout
        switch to a virtual console
        login as root
        dpkg -i /path/to/xdm.deb

    Once you have done that, you can switch back to X, login, and
    run tk-dselect to perform the remainder of the upgrade.


This could be made even easier for the admin by creating a shell script in
/tmp containing the correct dpkg command line.  if the install method is
ftp or nfs (rather than mounted disk) then copy xdm.deb to /tmp as well.


Alternatively, put xdm on hold, do the upgrade, unhold xdm and then
print a similar message telling how to upgrade xdm manually. Might cause
problems, though, if some packages are dependant on a newer version of
xdm.

BTW, rather than hard code this to be specific to xdm it might be better
to have a text file containing a list of package names which tk-dselect
can't upgrade automatically.  xdm is the only one i know of now but there
might be others later (The X server itself, perhaps?).  



Another point to think about is whether such a program should be setuid
root or whether the admin should su to root before running it. It should
be possible to make it safe if there is a, say, 'dpkg' group and your
tk-dselect is owned by root:dpkg and mode 4754.

Craig

--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: