On Fri, Oct 20, 2000 at 01:37:40AM +0300, Eray Ozkural wrote:
> Anthony Towns wrote:
> > 20k packages probably imples about 100 gigabytes of archive space,
> > multiplied by a factor for however many new architectures we start
> > supporting. Depending on how much more bandwidth is common and how much
> > disk space is available, we may well have other things to worry about
> > than how well our hash function works or doesn't.
> good point, let me think about the archive a bit. hmm distributed
> archival system? [apt-proxy is not that] :)
Well, that might not be necessary: we might find that we top out the
number of packages we want at 10k, and decide to focus more on just
maintaining and enhancing those rather than packaging more stuff, or
we might find that disk and network keep pace with Debian so while
we're always large and time consuming to mirror, it's not all that
unpleasant. Or we might find that disk keeps pace, but bandwidth doesn't
so we have to find some better way to mirror stuff as far as bandwidth
usage goes, but that actually storing packages is easy and fine. Or
something else might happen.
> > Stuff in the future is inherently unpredictable outside of academia
> > (inside of academia it's only predictable because you can say "assume
> > these are the problems we'll face, how can we solve them").
> yea, rough consensus and working code, right? i guessed that, but it
> was presented as the best implementation strategy (and it hadn't seemed
> to me that way)
It's a best implementation strategy given our existing desires and
constraints. One of which is programmer time, and another of which is
acceptability to the existing ftpadmin people. It's not an academic
solution, although obviously it's informed by academic pursuits.
> i would rather write a new fs that does dirs and symbolic
> links right :)
That'd be more useful for the BTS than the ftp system. (You can't
guarantee all our mirrors will use said fs, eg)
> gimme some other problem to solve then :) you know we academics can't
> really identify any problem in the real world. ha ha.
Academic solutions probably won't be directly applicable to Debian
though. Debian's far too political and complicated and entrenched to end
up with ideal solutions. So if you want to do something pristine and pure
and *correct*, you're probably better off just writing a paper.
If you want to do something that'll work with Debian, tattoo "compromise"
on the inside of your eyelids, and get something that's an incremental
improvement on what currently happens.
I'm sure there's some simple version of all the highfalutin ASCII art you
drew for the sectioning business, that you could demo and get added to apt
which would be useful, but I don't know what it is. Have a look back over
what Jason and I were talking about back in August about this. Generalising
the "Section" header and suchlike.
> working on package categorization now, so you guys make sure that
> you have some symlink-farm support :)
Package categorisation should just go in the Packages file and be
handled by console-apt or dselect, it doesn't need to be visible in the
file system (and probably won't be: all those symlinks are actually a
significant hit on mirror space and such, with the number of packages we
already have).
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgppFir0ycChh.pgp
Description: PGP signature