Christoph wrote: > How about having a non-free section in each distribution but then putting > the packages into the proper places through symlinks? > > I.e. the metrox wrapper would go into the x11 section where you would > expect such things. But it would only be present through a symlink into > the non-free section where the real file is to be located. I'd only like this if the packages were clearly identified as being non-free in dselect (and other front-ends). Mixing proprietary packages in with non-proprietary packages should only be done with some fore-thought, otherwise the user will end up with a proprietary system. :-( > If Cd-Roms are made then obviously a couple of dangling symlinks exist. > The Cd-Rom owner could then retrieve the non-free directory tree via ftp > and have a complete distribution. I sort of like what Bruce wrote earlier about possibly using a union filesystem, where some files would be downloaded from the net, and some could be located on a CD, or a mounted partition. I think you can do this with IFS, but I heard is was somewhat broken. I think amd has something for this too. Maybe the "access" methods from dselect could be improved and put into a separate program so that dpkg could use them. > I am having a hard time finding stuff with the current scheme. Its very > annoying that pine, pico and ncftp are separate from the scheme of > packages that we use otherwise. The list of packages presented is overwhelming. There needs to be some more support for different ways of finding and installing packages. I'd like to see a view in dselect that ordered packages in reverse cronological order based on the date they were uploaded. dselect does show the "new" packages, but only for the first time you look at it. I'm going to start work on way of installing packages via a cgi script -- experimental, of course. This would enable us to build a "map" of the various packages using hypertext, complete with descriptions, install instructions, dependency information, gotcha's, related packages, etc. When the user (authenticated, of course) clicks on the link to actually install a package, a java-based telnet applet will load which will handle the I/O from dpkg. The disadvantage of this scheme is that it will only work with Java-enabled clients such as Netscape (no lynx). :-( Eventually, we could develop a way of writing the package postinst/prerm (and other) scripts so that conforming packages would have all I/O handled via some other simplified mechanism. Then generic cgi scripts could be used to handle the installation prompting and questions. This would also be a nice solution (I think) for developing tools for installing/configuring packages remotely. Just write perl scripts to send data to the cgi scripts running on your remote machines. Comments? Should I do this? Cheers, - Jim
Attachment:
pgpNuMXhoqUFI.pgp
Description: PGP signature