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