[FINAL, for now ;-)] (Was: Re: package pool and big Packages.gz file)
final thoughts ;-)
On bigger and bigger Packages.gz file, a try
The directory structure looks roughly like this:
Contents of rel-chinese_0.9_all.pkg is as following. rel-base
or even rel-woody is just much more complicated. Hope so. rel-chinese.deb
is nearly an empty package.
Maintainer: Anthony and Cleopatra
Depends: rel-base (= 200), abba (= 1989-12), beatles(= 1979-100), garbage(= 1998-7)
wearied-ear (= 2.1)
Provides: music | abba | beatles
Description: Simplified music environment
This 'task package' installs programs, data files, fonts, and
documentation that makes it easier to use Debian for
Simplified music related operations. (Surprise, surprise, garbage
didn't provide music!)
Note, music is a virtual package provided by adda and beatles.
Contents of abba_1989-12_all.pkg is as following.
Maintainer: Old Man Billy
Depends: wearied-ear (>= 2.0)
Description: A Swedish Music Band
ABBA is popular in 1980's in last millenium. Don't be confused by ABBA
and ADDA which is a heavy metal band.
Here, music is a virtual package provided by packages abba and beatles.
Let's simulate some typical senarios here.
1) apt-get update
There're roughtly two purpose for this action. One is to get an
overview, to ease up further processing like virtual packages; another
purpose is to install a specific package, or do dist-upgrade.
On the second purpose, apt-get here will do nothing. (See below)
On the first purpose, apt-get will have to download and parse the
current distribution's .pkg file according to user configuration.
Say, to download rel-music, and then see the virtual package music
is provided by abba and beatles.
So, generally, ``apt-get update'' will deal with rel-some_XXXX_all.pkg
to get all of the overall information it will need further on.
Then, where does the rel-some_XXXX_all.pkg get its information? We don't
want the release manager to track down all of these information. So, where's
katie? ;-) I think the trade-off is worthy (Indeed, only katie get to be a
little more complicated) considering the scalabily being gained. Read on.
2) apt-get install abba
apt-get will first parse the previously downloaded rel-music.pkg, and get
abba is at version 1998-12, and it depends on wearied-ear (>= 2.0) and wow!
rel-music happens to provide wearied-ear (= 2.1), that's okay. Then apt-get
go on to download its .pkg and parse it, and so on.
When all required .pkg were downloaded and parsed (an updated Packages.gz)
apt-get then go on to download and install every of the debs.
(Maybe there will be more complicated issues, only let me know. See what's
Thus, minimum data downloaded. ;-)
3) apt-get dist-upgrade
I don't know the details, but I think it's not very complicated given above
information. (All necessary things are there, aren't they? ;-)
4) Packages upload
.pkg file is generated automatically. No extra burden on most of the
developers. And developers could upload just as frequently as they see
Katie will be a little ;-) more complicated.
Package will get to be deleted from package pool only when no rel-XXXXX
depends on them. rel-XXXXX are treated specially.
And some fine tuned mirror could be setup.
And release management could benefit from Bug Tracking System and more
flexible. IMHO. ;-)