Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
The new dselect should allow you to mark a package for re-install. I just managed to delete all .so files in my X11R6/lib. It's be nice if I could just mark all the affected packages for reinstall in dselect, instead of having to download and reinstall by hand. -- See shy Jo. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Hi again, I have something for the dselect etc. wish list: We would like to be able to put the packages in an unpacked state on a read-only NFS disk and then automagically create symlinks from the system directories to the NFS disk on our target systems that form a cluster. This of course makes sense only for application-level programs, not for basic system utilities. An ideal dpkg implementation would allow to store all files that belong to a package in a special directory, the packages directory. In our installation, it is named /usr/local/packages and located on an NFS disk. Each package has its own subdirectory. Now, we install new packages only there, and then "activate" them on each machine in the network by simply creating symlinks from the system directories to the packages directory. To automate this, the installer program should unpack the debian package into a subdirectory and create a list of links to be made from the system directories into that subdirectory. This implies that the files in a package can only be installed in some well-defined set of system directories. To activate a package on any system that mounts the packages directory, we would just need a script to set up the symlinks. The packages directory could reside on CD or on read-only NFS disk, no local disk space beyond the links would be used. If a package gets removed or changed, we just have to remove dangling symlinks. There are some problems: - Most installation scripts install the info files using install-info. This could easily circumvented by providing a file that stores the information needed to link in an info file, and scanning this file when the package gets activated on a system. - Configuration files must be created/edited when the packages directory is created. If a target system requires different configurations, it just replaces the symlink by the actual config file. - Directories in /var must be created on the target systems, and the files copied in, instead of linked, in the assumption that they will be modified. I have used a semi-automatic version of this scheme for some time, and it works very well. I should be happy to contribute our experiences. Regards -Christoph -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
On Thu, 17 Apr 1997, Leslie Mikesell wrote: > One more idea to throw in the pot: > > How about including smbfs in the base kernel and allowing installation > from a Win95 or NT share? Almost every office is going to have one > of those around where you can share out a CDROM with a couple of > mouse clicks. You could even do from with Windows-for-WorkGroups if you Win95 _DEFINITELY_ doesn't support RockRidge. AFAIK, neither does NT. Oh well... > mangle the names to fit but that probably isn't worth the trouble. > This might help a lot of people get their first Linux system up on > machines that don't have their own CDROM drives. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
'Peter Iannarelli wrote:' > >Hello all: > >As I'm sure everyone is aware a new project has been initiated >to replace the currenct dselect package maintainence facility >with the goals of enhancing its functionality and resolving >some of the existing package maintenance problems. Look at http://www.netaxs.com/~cjf/debian/selectmenu.tgz for some of my ideas. -- Christopher J. Fearnley | Linux/Internet Consulting [EMAIL PROTECTED], [EMAIL PROTECTED] | Design Science Revolutionary http://www.netaxs.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | "Dare to be Naive" -- Bucky Fuller -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
On Thu, Apr 17, 1997 at 10:30:40AM -0500, Leslie Mikesell wrote: > How about including smbfs in the base kernel and allowing installation > from a Win95 or NT share? Almost every office is going to have one I started fiddling with the dselect method scripts last week, in an attempt to implement an SMB method. Some unsolved problems as yet, and no time at present to work on it. But will let you know. Hamish -- Hamish Moffatt, StudIEAust[EMAIL PROTECTED] Student, computer science & computer systems engineering.3rd year, RMIT. http://yallara.cs.rmit.edu.au/~moffatt (PGP key here) CPOM: [ ] 40% -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
On Apr 15, Dale Scheetz wrote > Isn't this already available with get_selections and set_selections? Yeah, but only 'oldtimers' know about that. I'd be nice if it could be integrated in a more user-friendly way into "dselect 2". Something like: Select Packages - Full list (provides collapsible tree list of all the packages - Package Groups (provides often-used configurations like 'C development machine', web server, etc. to help newbies get a working system quickly.) - Read "Selection list" (for sysadmins doing installs of Debian on many machines) Of course, there should also be a way to save the "selection list" to a file somewhere. Christian pgpCesblAAnwi.pgp Description: PGP signature
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
On 14:30:40 Leslie Mikesell wrote: >>One more idea to throw in the pot: > >How about including smbfs in the base kernel and allowing installation >from a Win95 or NT share? Almost every office is going to have one >of those around where you can share out a CDROM with a couple of >mouse clicks. You could even do from with Windows-for-WorkGroups if you >mangle the names to fit but that probably isn't worth the trouble. >This might help a lot of people get their first Linux system up on >machines that don't have their own CDROM drives. > >Les Mikesell Les, Now thats a great idea! Think about it guys, this is good! Paul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
One more idea to throw in the pot: How about including smbfs in the base kernel and allowing installation from a Win95 or NT share? Almost every office is going to have one of those around where you can share out a CDROM with a couple of mouse clicks. You could even do from with Windows-for-WorkGroups if you mangle the names to fit but that probably isn't worth the trouble. This might help a lot of people get their first Linux system up on machines that don't have their own CDROM drives. Les Mikesell [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
I like the consept of dselect as it is but som improvments are welcome. The sugestions is sorted in thre cattegorys: 1) Small improvments to dselects interface. 2) Bigger new featurs to dselect. 3) New / improved featurs involving possably changes to the pakage managment system. Lets start with 1) small improvments to dselects interface... 1.1 The enter key When the user press ENTER no strange fings must happen. If its a menu, the higlited item is shosen (as it works now). Some sugestuons for other cases: ENTER in the package list: pop up a screan describing the pakage curent status in verbose text at the top. The rest of the pop-up is a menu wher You can chose wath to do with the pakage. All the pakage status in verbose (instal, purge, hold, unhold etc). Seperated by a line some options not conected to the curent package (abort menu, check dependensis and go to main menu, go to main menu without checking dependensys, abort session whitout saving changes, show pakage deskription full screan (aborted whit enter), show pakage filelist in full screen, change preferenses/view etc). ENTER in the dependesy resuluton list shold be much the same whit som extra opten like: abort dependency screen whitout saving shanges made (inkluding the changes premade by dselect). The view description option above is werry neded here. All this option shuld have an accalrator key asigned. It shold also be presented in an cosistent way in the menus, eg in squar brakets. This will help newbes bekome DEITY-gurus an fly along... 1.2 Change focus If the user press TAB Focus shold be moved. In the package list focus is cycled thru deskripton window (allow scroll of deskription whit cursor keys and space), some menus att the top of scrern (preferenses, help etc) and the man package list window. The option to scroll the deskription window with a accelarator key shold be keept. 1.3 Limited view When presing enter on the header line the first menu shose shuld be to toggel the if that group shold pe precented or not. In the begining all sections shold be closed. This will make it easier to navigate the huge set of debian pakages. 1.4 Posability to treat recomends as recomends Or shold I say as sugests. This shose shold be posably to do from the preferens menu. It's ok (possably best) if the preferenses is reset to some default when the program is restarted. Changes to the default preferenses should be posably thru a config file (dotfile). 2) Bigger improvments 2.1 Searched view A advansed serch screen would be nice. It shuld seartch the pakage names, descriptions, filelists, possably depenndensis in a powerfull manner. You may then go to a package list and chose (like usual) among onle those page maching Your querry. Dependesy resulution most of corse check all pakage. It would be nice to be able to save the querrys as well 2.1 Loging / Supressing of mesages Loging of what dselect have done and any problem wold be nice. Supression of the famus skipping mesage whold be nice. A preeview what dselect is about to do wold be nice (a list of packages to install/deinstall/perge). If the preeview is alreddy sorted in dependency order that wold bbe nice. Dependency sorting is allredy in the DEITY project? else that is a major sugestion! 2.2 Different default for different distrubutions. An exampel. DEITY is ponting both att stable and unstabel. I do have a pakage from stabel in status unhold and want it to be automaticly shosen for uppgrade if ther is a new version in stabel. But I only want it to upgrade to unstable if I tell it to. What i want is some mekanism to tell that I want to know about new stuff from some source and I want to bee able to install it by selecting it but I dont want to automagicly uppgrade to it.. undurstandable? 3.1 Pree Configure If a pakage has a PreeConfigure script that shuld be run from DEITY when the pakage is shosen for install BEFORE the dependensy resolution given the script a change to resolv the dependensys in a more context avare manner. This will add posabilatys to maake great meta pakages. This dose not demand that the config info is stored in the selection database but it be nice to at least hav a pointer to the config info in the database to make it posibly to distrubute it automaticly betwen maskines. Posably adding an uninteraktive option to install making pakages having wrong preeconfiginfo fail insted of go interaktiv on install (makes it even more possably to make automated upgrades of several maskines). 3.2 Meta and slave package Slave pakages is pakages that is normaly not shoved i DEITY selections lists. if thay are neaded they are chosen automagicaly an if the ar not neaded they are removed automagicaly. For smal pakages that take no costom configuration and comes in only one version. It shold be possably thru the preferenses to make DETIY treat slave pakages just like ordanary pakages. Meta pakages is pakages that makes it esier to install other pakages with a higer lev
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Dale Scheetz writes: [snip] > Isn't this already available with get_selections and set_selections? What about a fresh, "from scratch" installation? (like a newby would encounter) 8-) -- -= Sent by Debian 1.2 Linux =- Thomas Kocourek KD4CIK - member of ARRL [EMAIL PROTECTED] --... ...-- ... -.. . -.- -.. - -.-. .. -.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
On Wed, Apr 16, 1997 at 10:14:30AM +0800, A. M. Varon wrote: > > If possible, it could look, feel and function like a midnight commander. > left pane are the .deb files, to the right could be the content, info, > dependancies to other files etc. which you could toggle. Hmmm. But more interesting is the package names (as presented now in dselect), rather than the filenames. I think the above would just be an interface to dpkg, rather than a nice friendly package management tool (which is what dselect and deity aim to be). Hamish -- Hamish Moffatt, StudIEAust[EMAIL PROTECTED] Student, computer science & computer systems engineering.3rd year, RMIT. http://yallara.cs.rmit.edu.au/~moffatt (PGP key here) CPOM: [ ] 40% -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Regarding the "wish list" for the dselect replacement: 1 A "what if" command: Tell me what you would do if I said "do it". I found with dselect I'd somehow told it to remove lots of things I hand't meant to, so recently I've been using dpkg directly rather than trying to figure out dselect. 2 A "merge in" command: Someone mentioned the get_selections and set_selections which is useful. But if I understand correctly set_selections replaces everything. I think it would be nice to have a way of "adding it to the current set from something". I doubt if it would be useful for single machine situations, but for an installation of several machines one might have a "core set" which is on all machines, but a few extra sets of packages which are enabled on other sets of machines. 3 In the less important but nice to have category: Choice of interfaces: e.g a perl/tk interface and an emacs interface. Richard.
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
If possible, it could look, feel and function like a midnight commander. left pane are the .deb files, to the right could be the content, info, dependancies to other files etc. which you could toggle. regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Andre M. Varon Lasaltech, Incorported Technical Head Fax-Tel: (034)433-3520 e-mail : [EMAIL PROTECTED] web page: http://www.lasaltech.com/andre.html =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
[EMAIL PROTECTED] wrote:
|and concerns. So fire away. Keep it short and terse.
This isn't quite about the interface, but about the package system
(may it just depends on the way it is implemented).
What I'd like to see is a way for the user to individuallt decide
whether he/she wants to install certain "sections" from a package.
"sections" are things like "doc" (/usr/doc?), "man" (/usr/man), "lib"
(/usr/lib?), "dev-lib" (compile-time libraries), "binary", "info"
etc...
This again merges into a previous point I raised of combining a few
related packages into one (e.g. mgetty-{docs,fax,voice,}) and let the
user pick from inside it.
Reference - the SGI inst system.
Cheers,
--Amos
--Amos Shapira| "Of course Australia was marked for
133 Shlomo Ben-Yosef st. | glory, for its people had been chosen
Jerusalem 93 805 | by the finest judges in England."
ISRAEL [EMAIL PROTECTED] | -- Anonymous
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Peter, Thank you for request for ideas and desires regarding the next improvement to the debian package management system. 1. Scripts provided by the package writer should only have access to files and directories specifically approved by the installer. 2. Most packages do not need to alter existing system directories or files, and should be installed and tested by an unprivelaged user (specified by the installer) in a directory chosen by the installer, and under which package scripts can create and modify files. 3. After testing, the installer should use ln -s, ln, or cp (as chosen by the installer) to integrate the package executables and files into the system. Ray Ingles and I, have spent some time discussing improvements to dpkg/dselect to permit users to take advantage of its dependency tracking without the security vulnerability entailed in always running it as root. The following is a first draft of a processing model (similar to the ISO network model) that hopes to provide the following: 1. Host selectable security - the installer chooses what level of trust (unprivelaged, privelaged, root) to grant to the package scripts. 2. Host testing - before the package is seen by other users, the installer can test the package 3. Portability - package writer can assume a single (or small number) of directories in which to create, modify, compile, configure, files and executables, independent of the platform or host cut here * Project: debian File:RFC: dpkg target model Author: Raymond A. Ingles Dr. Robert J. Meier, Jr. History: 97-04-03 -rjm- file creation * Goals ** ease of use The package provider and the installation process should automate as much of the installation and removal as feasible for ease of use. All operations should have defaults to support ease of use. ** security As far as possible, malicious or buggy package installation should not endanger existing installations. All default operations should be defined by the install procedure so as not to endanger existing installations. All package-suggested operation parameters must be individually approvable by the human installer. Successful or unsuccessful installation is completely reversible. ** flexibility As far as possible, package installation should be configurable by the host to meet individual user needs and concerns. As far as possible, package installation should be configurable by the host to meet individual package needs and concerns. All install operation parameters should be selectable by the installer. All install operation parameters should be suggestible by the package. ** repeatability As far as possible, package installation should produce the same behavior on different hosts (e.g. the package provider and the user). By default, installation will be done under a single host-selected directory with an image equivalent on the user host to that to the package provider host. * For design purposes, installation is divided into the following phases. ** (Template) Each phase needs to answer the provide answers to each of the following questions. The answers must express the minimum/default/maximum supplied by/required from the package/host. *** System privileges *** Host information *** Package information *** Intended results *** Prior assumptions *** Actions *** Validation *** Customization ** Download *** System privileges Minimum supplied by host: write a host-specified file as $DOWNLOADER. Default supplied by host: write a host-specified file as $DOWNLOADER. Maximum supplied by host: write host-specified files as $DOWNLOADER *** Host information Minimum supplied by host: $PACKAGEROOT Default supplied by host: $PACKAGEROOT Maximum supplied by package: filenames *** Package information Minimum supplied by package: number and description of required files and directories. Default supplied by package: number and description of required files (1) and directories (1) *** Intended results Minimum supplied by host: transfer the package to local file system Default supplied by host: transfer the package to local file system Maximum supplied by host: transfer the package to local file system Minimum supplied by package: from package file Default supplied by package: ftp, cd-read, floppy-read Maximum supplied by package: from net, cd, floppies, tape, etc. *** Prior assumptions Minimum supplied by package: the complete package is transferrable as a single file Default supplied by package: the complete package is a compressed tar file *** Actions Minimum supplied by host: Create a specified file in (a directory chosen by host) writable by $DOWNLOADER. Default supplied by host: Cr
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
In message <[EMAIL PROTECTED]> you wrote: >Adam Shand writes: >> This is *just* to get newbies installed and working. I'd do something >> like have 3 options. ... >> ...and a full install ( the two before plus X windows). > >Thus the the true newbie, who wants most of all to dial up her ISP and use >her browser, is forced to do a full install. > >I suggest: > >1) Basic Unix, with enough dev stuff to compile a kernel. *No* networking. > >2) 1), plus basic networking (MTA & MUA, but no servers). For a newbie who only wants to pop his mail Netscrape? :) Actually the idea of meta-packages was kinda nice and easily incorporated into the existing dependencies mechanism. Dimitri
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
[EMAIL PROTECTED] wrote: > > Adam Shand writes: > > This is *just* to get newbies installed and working. I'd do something > > like have 3 options. A developement box (nothing but baisc utilities and > > compilers),... > > How many newbies are going to want this? > I suggest: > > 1) Basic Unix, with enough dev stuff to compile a kernel. *No* networking. > > 2) 1), plus basic networking (MTA & MUA, but no servers). > > 3) 1), plus X. > > 4) 2), plus X. I don't have the context of the original suggestion handy. Has anybody suggested that the "tool" simply supports externally-defined package sets? Then, any number of configurations can be defined and offered in distributions, web sites/archives, etc. The DEITY team needs only to provide a general capability and not get into the battle of actually defining the packages. Of course, the tool would help as expected by ensuring dependency existence and ordering and "all that". -- ...RickM...
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Adam Shand writes: > This is *just* to get newbies installed and working. I'd do something > like have 3 options. A developement box (nothing but baisc utilities and > compilers),... How many newbies are going to want this? > ...a network box (basic utilities and networking stuff, including > prefered MTA and MUA etc) ... Since you left out X, I assume that this box is meant as a network server. For a newbie? > ...and a full install ( the two before plus X windows). Thus the the true newbie, who wants most of all to dial up her ISP and use her browser, is forced to do a full install. I suggest: 1) Basic Unix, with enough dev stuff to compile a kernel. *No* networking. 2) 1), plus basic networking (MTA & MUA, but no servers). 3) 1), plus X. 4) 2), plus X. -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED]Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
On Tue, 15 Apr 1997, Wichert Akkerman wrote: > > This thread is being issued to provide all individuals and > > organizations an opportunity to voice their requirements > > and concerns. So fire away. Keep it short and terse. > > Here's a simple one: the ability to create a tagfile. We had to install > 25 Linux machines here a while ago and it is a pain to select to same > package every time in dpkg. I would like to be table to create a file > with a list of packages I want to install and then tell dselect on > another machine to use a specific tagfile and go from there. > Isn't this already available with get_selections and set_selections? Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
> The odds that Mr Iannarelli is starting this thread just to > concentrate the flammage, flak and junk into one thread which he can > easilly killfile is astronomical =) This is especially probable given his > insistence on exact spelling in the subject... Excuse me, but this is completely uncalled for and the only true point is about concentrating things into one thread. Nobody is killfiling anything, except possibly your name if this is is the only thing you have to say. If you have something constructive to say, then please go ahead. If not, then don't waste our time. We have work to do. Brian ( [EMAIL PROTECTED] ) --- It's not the days in your life, but the life in your days that counts.
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Probably I'm going to say the obvious, but... On Mon, 14 Apr 1997, Rob MacWilliams wrote: > 2. I know there has been much traffic about the interface [...] > Now all that is needed is a keystroke sequence to open and close the > categories. The closest piece of software out now that would be similar > is the Netscape News Window. That would be really nice to have. *Personally* (don't quote me ;-) I like the Windows Explorer way: left pane with collapsible directories, right pane with stuff, and add one bottom pane for information... much like current dselect but a bit more organized, and FASTER, PLEASE. I'm not into that pre-configured idea, but I know many users would like to have it. It's nice, but please let me customize it. For example, in a developers environment I want C, and Fortran, with all the programs that are "needed" (things such as make, developers' libraries, and an editor that "understands" C, not necessarily Emacs), but I DON'T want Phyton, or Tcl/Tk, or C++ (I'd like to have the time to learn all those, but heck, I have some work to do, too). Possible categories are: Desktop, Network, TeX, Developers, GUI (be that KDE or X+properly configured window manager like AfterStep, fvwm2, others). Mixing of categories should be allowed. There has been some talk about how to implement this, but I guess you'll need to create some "configuration packages", i.e., packages that provide just configurations, and depend on other packages. But more important is a recent thread on this group: NFS installations, in the sense that Debian could be the first distribution that supports site installations. We already provide packages for NIS, NFS root booting, cfengine, and things like that, but in my experience, these are not plug-and-play kind of things. Lots of people have devised methods for maintaining networks of Debian machines, but we still lack a "generic" solution. We need something in the lines of: install the server machines, make groups, and choose what to propagate to the different groups. For example, the server may have Apache installed (because of dwww, for example), but not the clients. In this scenario "dpkg --get-selections ..." fails because it will install Apache on the clients which is not needed. NFS-root works, but it has one small problem, it shares root. And NFS booting can be a pain sometimes. Also, someone already mentioned this: one must be able to choose what to share, say /usr and /var, but not /usr/local, without much hassle. Obviously this is monolithic work, but Debian's meant to be "The Universal OS", isn't it? I hope this helps. Marcelo Magallon
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
On Tue, 15 Apr 1997 11:00:00 +0200 Wichert Akkerman ([EMAIL PROTECTED]) wrote: > > This thread is being issued to provide all individuals and > > organizations an opportunity to voice their requirements > > and concerns. So fire away. Keep it short and terse. > > Here's a simple one: the ability to create a tagfile. We had to install > 25 Linux machines here a while ago and it is a pain to select to same > package every time in dpkg. I would like to be table to create a file > with a list of packages I want to install and then tell dselect on > another machine to use a specific tagfile and go from there. dpkg --get-selections dpkg --set-selections Phil.
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
> This thread is being issued to provide all individuals and > organizations an opportunity to voice their requirements > and concerns. So fire away. Keep it short and terse. Here's a simple one: the ability to create a tagfile. We had to install 25 Linux machines here a while ago and it is a pain to select to same package every time in dpkg. I would like to be table to create a file with a list of packages I want to install and then tell dselect on another machine to use a specific tagfile and go from there. Wichert.
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Hee!!! The odds that Mr Iannarelli is starting this thread just to concentrate the flammage, flak and junk into one thread which he can easilly killfile is astronomical =) This is especially probable given his insistence on exact spelling in the subject... Hahahahahah What a lame thread. You are so obvious and apparent =) SirDibos On Mon, 14 Apr 1997, Peter Iannarelli wrote: > Hello all: > This thread is being issued to provide all individuals and > organizations an opportunity to voice their requirements > and concerns. So fire away. Keep it short and terse. > > Please ensure that "DEITY TEAM --" is in the subject line > as it will aid in tracking your responses. We will endeavor > to take everyones requests and comments into account but > that does not guarantee all requests will be implemented. Hahahahahahahha!
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
>2. I know there has been much traffic about the interface, but I think the >best I've seen for this type of material is a nested list of packages. Start >the top with all packages, then go to stable, contrib, non-free... After that >break them down by group, i.e. admin, base, ... The thread that could tie all >of these together is the ability to make some of these disapear. Yep that would be good. As I see it dselect/deity has three purposes. 1/ To install debian on a fresh system. This should be as simple and painless a process as possible. I would recommend sacrificing functionality for simplicity. This is *just* to get newbies installed and working. I'd do something like have 3 options. A developement box (nothing but baisc utilities and compilers), a network box (basic utilities and networking stuff, including prefered MTA and MUA etc) and a full install ( the two before plus X windows). 2/ To manage the packages that are installed or you want to be installed. This should be a nice friendly way of adding or removing packages. I think an X config option is overkill and would just go for a nice simple curses or slang interface... others may disagree... This is the meat of the program. It needs be easy enough to use by newbies (or relative newbies) but still have the advanced options that a power user would want. 3/ To upgrade your system to a new version of Debian. The basic option for this would download and then upgrade everypackage that was currently installed on your system. I favor the 'pine' method of making things easy. Ask questions all the time if they want to do somethign and allow the advanced user to turn all the *stupid* questions off. Adam. - Earthlight Communications Limited P.O. Box 5301 Adam Shand (fax) +64 3 477 5463 Dunedin, New Zealand Systems Manager(voice) +64 3 479 0303 http://www.earthlight.co.nz/larry/
Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Hi all, Since the gentleman requested, and will soon be deluged with mail, I decided to get my two cents in early. 1. Please include a download status indicator. i.e. time remaining. I am using a link that only lasts three hours, and then shuts down. An indication of how much time is needed/remains would give me a guide as to which order I want to grab packages. 2. I know there has been much traffic about the interface, but I think the best I've seen for this type of material is a nested list of packages. Start the top with all packages, then go to stable, contrib, non-free... After that break them down by group, i.e. admin, base, ... The thread that could tie all of these together is the ability to make some of these disapear. For Example: -All Packages -Stable -admin -acct -base -adduser -Contrib -Non-free Now all that is needed is a keystroke sequence to open and close the catagories. The closest piece of software out now that would be similar is the Netscape News Window. The scrolling through dselect can be tiring. I agree that dselect is the greatest tool for software management I have seen, but there should be a way to condense the number of packages displayed on the screen at any one time. This can avoid information overload, which IMHO is dselect's flaw. I'm not sure of the best way to arrange the dependencies. Maybe a toggle to arrange packages by dependencies or catagory. I hope this has been helpful and not a waste of bandwidth. Thanks "Change is inevitable, except from a vending machine." Rob MacWilliams [EMAIL PROTECTED] N9NPU
