On Mon, Mar 25, 2002 at 01:23:23PM -0400, Ben Armstrong wrote: > On Mon, Mar 25, 2002 at 05:57:01PM +0100, Fabio Massimo Di Nitto wrote: > > What about applying to a similar structure that is used for main contrib > > non-free?? > > > > something like base admin net so that a sources.list file can look like: > > > > deb <mirror>/debian unstable main/base main/net contrib/* non-free/web > > > > where * means all the sub categories that belongs to contrib. > > at this point I think 2 problems can be solved in one shot: > > > > 1) reducing the size of Packages > > 2) give the end user a higher flexibility in selecting pkgs > > (EX: why do I need to have gnome-audio if Im installing a dns > > server?? maybe on > > an old i386??? ;) ) > > 3) Im tempt to say reducing network load but.. well.. that's another story. > > > > It's obvious that your sources.list get more complex to handle but we also > > have really nice tools like debconf to help users, don't we??? > > Under your proposal, if I need even *one* package from a section that I > currently don't need, I need to include the whole thing. The granularity > is too coarse, and therefore only addresses the needs of a limited number > of users facing this problem. You could do it by point apt to the pool/main/y/yourpackage directory and downloading it from there or just downloading the Debian package manually. > What about going the whole way and inventing a debian package meta info > protocol, loosely modeled after NNTP: > > - instead of whole Packages files, have the archive provide "headers" > with minimal info (a unique id, package name, brief description) We can do that using ftp/http with just normal files in the pool. > - the client may "subscribe" to groups (i'm being deliberately > vague about what a group is ... a section? all packages of a certain > priority? hand-picked subset of packages? it doesn't really > matter) We can also do that in the dist directory. That will be dists/<group> or dists/<release>/<group>. > - the client may either fetch individual package entries as needed or > nab a whole mess of them at once. the client should have smarts about > fetching not just the desired package entries, but also selecting > entries that may satisfy dependencies. We can just fetch the individual package files from the pool. > By splitting up Packages down to individual entries, it allows extremely > small subsets of packages to be placed in the local copy of the Packages > file. Furthermore, because entries would have unique ids, only new package > entries need to be downloaded each time. Yes, I think we should just use MD5. > Local systems on a network needn't even store the Packages file anymore. > They can simply query the Packages database server for the lan. Yes, but I don't see a need to make a special protocol for it. Using http/ftp(/rsync) would be fine I think. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: jeroen@openprojects
Attachment:
pgpzqov6Tbbbl.pgp
Description: PGP signature