Re: RFC: implementation of package pools
Anthony Towns wrote:
> "completeness"? It is complete. It does everything that it needs to do:
> it provides a compatibility layer between the old dinstall and the new
> software, it handles the key features of package pools, it handles the
> old and new release mechanisms.
>
does it support automatic testing, upload and removal of packages
from the pool? those would be the most basic features of a package
pool implementation.
> What symlink-farms would this be? The ones that won't exist?
>
distribution symlink-farms. ie, your testing becomes just a symlink
farm into the pool.
> Actually, from my experience, it's not at all important. Take our fondness
> of Linux, for example: it's written in a basic procedural language
> that hasn't really had significant changes since 197x (think object
> inheritance, lambda functions, generics, namespacing), it's external and
> internal design basically just mirror previous versions of the same thing
> (compare to microkernels (Hurd, say), capability oriented systems (Eros),
> object based systems (Self, if you'll let me push things), or distributed
> systems (the best of which I can name is Plan9)).
Yeah, linux isn't the highest quality OS out there! It just works
good enough on a great number of devices that's why we're using it.
Think gcc, and say that again. [uses a lot of optimization algorithms
from research. so?]
> And continuing the example, you'll not how B+ trees, even though they're
> old enough and standard enough to be taught to undergraduates, aren't
> actually the basis of the main database we actually work with ever
> day: ext2.
Yeah, OS/400 has a nifty B+ tree based data index system.
Big iron rules! :)
ext2 sucks by the way. I wish I had some free time to teach those
arrogant guys on the linux-kernel list how to write a robust fs.
> You say you're into algorithms. Maybe, then, you'd like to do some
> peer review of the algorithm used in "testing", which is hidden away in
> auric:~ajt/testing/testing/dpkg.c in the check_installable() function.
>
I looked at that, but why do I have to find what's hidden? :)
It's about Depends: and Conflicts: things right? :) Whatever.
What do you do there, exhaustive search over all propositions?
It's typical C code, and not well commented. If you can provide
the comments here, then I can review the algorithm.
> Hmm. Except you can't look at that because you're not an actual developer.
> Well, try http://auric.debian.org/~ajt/code/testing/dpkg.c instead. Read
> up on the SAT problem first, perhaps.
>
Not my area of interest, but there are a couple of new heuristics for
SAT if you want state-of-the-art code.
I don't know if it's needed, though. I haven't given much thought
to it, I'm waiting for your detailed comments on the code first.
Are you sure you need full SAT for this? Or perhaps because of
the problem space, it might not be that difficult. If there
are time/space problems we can move to the next "better" search
algorithm.
Why do you assume that I don't know about satisfiability problem? I'm
telling you I'm a CS person. :? Are the CS graduate students in your town
that ignorant? [ doin' my msc, and it's impossible to avoid knowing
these when you've been for 6 years at a CS dept. ]
> If you want to get rid of the
> "complicated" thing, you need to trim down the number of packages,
> users and maintainers to something much smaller: you're not going to
> end up with an uncomplicated distribution with 20k packages.
>
You can make it more complicated to get rid of the complications.
One of these is automating every common task. That's why I'm
insisting on "have you automated this?" "have you automated that?"
"are you doing this with a tool?"
> > 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.
>
> You'll note the "make" is a long way from prolog.
>
You can't write either of them without surveying research papers.
make's forward and backward chaining might have become more
commonplace, but still 90 percent of the so-called programmers I
see around (from personal acquaintance) wouldn't be able to code it.
A real prolog interpreter/compiler would be out of question for
them anyway!
Try writing an efficient LALR(1) or LR(1) parser generator without
studying compiler research. I've got my own LALR(1) parser framework
and it's not better than bison. :(
> If I cared I might have to do some paperwork. I don't. Please, go ahead
> and get something that works to demo so people can judge it for themselves
> without having to read boring academic papers they don't care about.
>
How to do that without reading any papers? I don't have a hard
line from my brain to the galactic library! Ontology stuff is
seemingly easy but very hard to get right. You need to know
what people did before you can design [at least in this subject]
> > It also needs some understanding of knowledge engineering in general.
>
> Categorisation will be useless if you need a degree in knowledge engineering
> to work out how to find a package, or to see why some ideal way of doing
> things is better than the current way.
Implementing it will need some overall sense of how an ontology
is engineered. That's why I'll go into some papers and review some
chapters from AIMA. Using it will be certainly easier than using
dselect!
--
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: