Re: RFC: implementation of package pools
Anthony Towns wrote:
>
> 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.
[I have a disturbing feeling that "we" doesn't refer to debian here,
but only a few sysadmins...]
With this rate of development in the free world, there's going
to be more than 10k high quality software packages in Debian.
> 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.
>
Good, then it means we'd have to find a better way to distribute
software than plain ftp. Not necessary for a couple of years I guess.
> > 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.
>
Okay. Shall we say, it's the decision of the programmers involved in
a particular implementation of "package pools" which has no guarantee
of completeness.
> > 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)
yea? what about symlink-farms for distribution dirs?
> 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.
That's true about pure theoretical work which doesn't apply directly to
situations like this. But if you're related to computer science in a way,
you'll know that practical work is a very important part of the whole
enterprise.
For instance in the field I study, that is algorithms/parallel programming,
you need to write a program that *no one else* can top, including
some random hacker who knows a bit C and a few scripting languages.
It's pretty much like that in many areas. How do you think B+ trees
that you see in the database implementations got here? From heaven?
If Debian's far too political and complicated and entrenched to end up
with ideal solutions, *it's debian's mistake* Debian organization should
be revamped to focus on "getting things right", then.
Free software doesn't mean low-quality software. On the contrary, debian
is favored for its "technical superiority" rather than being endorsed
by RMS. [
Though freedom isn't to be neglected ]
So those papers that you're implicity disgracing probably has a lot
more work put into them than many of the fellows here did. And quality
software. I suppose no one would ever write "make" or "yacc" if everyone had
this simple ideas. Being simplistic doesn't always work.
BTW, a lot of significant contributors to free software come from
CS departments, so be more sensible. WHO ON EARTH DO YOU
SUPPOSE WOULD WRITE SOMETHING LIKE TeX?
> 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.
>
ad hoc things don't always build up to better things. that's what
they teach to any engineer.
you know, that's why people first do some design and then get
to realizing it.
> 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.
you're wrong; what we were talking about was that a simple categorization
(a la Tucows) won't do it for Debian.
Have a look at some the papers I referred to on that thread, there
are various technical issues to be thought there. [this isn't
a trivial matter, you need to do some paperwork]
It also needs some understanding of knowledge engineering in general.
> > 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).
I don't think package categorization can go wholly into Packages file.
An ftp symlink view would be nice, though that can also be done in http.
Ultimately, it should go into a package manager and be made available
as a library.
I'd be very glad to hear some concrete suggestions for package
categorization. [ie, not involving patching "Section:" field]
Thanks,
--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo
Reply to: