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

Re: Non-free section

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 
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?


 - Jim

Attachment: pgprOkP6tzLvO.pgp
Description: PGP signature

Reply to: