ideas about fcc-pool support
Hi,
as we now have a list here, forwarding some ideas ...
Cheers,
Andi
----- Forwarded message from Andreas Barth <aba@not.so.argh.org> -----
From: Andreas Barth <aba@not.so.argh.org>
To: dak-disc@nocrew.org
Subject: ideas about fcc-pool support
Date: Sun, 20 Mar 2005 12:33:41 +0100
Message-ID: <20050320113341.GJ12322@mails.so.argh.org>
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.5.6i
Hi,
some ideas about the splitted pools for fcc/....
IMHO, requirements are:
- it need to be possible to have packages different for different suites
(like: sarge has 11 archs as fcc, etch and sid not)
- the solution should be generic, and should allow to have multiple
reduced pool-trees
- the new trees should behave like the current one, e.g. StayOfExecution
- allow in some way to push an arch into a new tree in small chunks
(e.g. .5 GB/day or so)
In addition to the generic ftp-tree, this needs one or more customized
trees (with the same structure as /org/ftp.debian.org/ftp) that only
have the part of the files that are required for that arch (called
"extra trees", "extra pool", ...). There are two ways when to create the
extra files (that should be hardlinked to the ones in
/org/ftp.debian.org/ftp for space considerations): Either change kelly
to do it during file installation, or create a new script that populates
an extra dir, according to the configuration. For deletion of the extra
files, the same possibility comes up: Either do it during rhona, or do
it in a new script.
Some random reasonings:
- there might be reasons to delete a file in an extra pool even if it is
not deleted in the main pool. That happens if the package is removed
in only some suites it is currently in, and the suites where it stays
are not in the extra tree, at least not for the architecture the
package is. That happens also if the arch=all-files are handled
different.
- It might be possible to create the extra pools based on the
override-files from denise, but I tend to create the pools directly
from the contents of the database - though that might mean to move
some parts of denise into katie.py (which could also reduce
code-duplication with natalie a bit?), or creating more code
duplication.
- Because of the just said, I tend to create the files in the extra
pools in a new script. The new script should also handle symlinking of
the packages files.
- For deletion, it's just more or less the same as currently, only in an
extra dir - so, no reason for a new script.
- To keep control of the extra files, I would create a new table that
has all files in the extra tree, and would reference to the table
files. This new table has also an last_used-entry that can be used for
pruning files in the extra pools. Of course, there needs to be another
table that just has a link to the different extra trees.
- For addition of a new arch to the extra tree, it should be possible to
tell the creation script to link at maximum a certain amount (in
bytes) of new files per run - in that case, probably linking of
packages files should be switched off for those archs. Hm, perhaps
that should happen in the way of an "override" (and the files will not
be deleted by rhona as long as the usage count is updated every day,
even w/o a packages file, so this is not too hard).
Any comments to these first ideas on implementation?
Cheers,
Andi
----- End forwarded message -----
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: