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

Re: Splitting Packages [was Re: ITP: mencal -- A menstruation calendar]



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: pgpPAVGwDzCvL.pgp
Description: PGP signature


Reply to: