Re: RFC: implementation of package pools
Anthony Towns wrote:
>
> > 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.
>
> We have no mechanisms to support automated testing. If you'd like to
> implement some, please go ahead. When it's written, tested, and generally
> accepted, *then* we'll see how it can and should be integrated into the
> archive. Not before.
>
I think only the interface should be specified and testsuites should
be left to package developer's desires.
> Of course it supports upload and removal of packages from the pool. That's
> it's whole point.
>
No, I'm saying "does it support automatic upload and removal?"
So a package goes into the archive without waiting for any human.
That's how tertiary storage systems should work AFAIK. This means
that any mandatory checks a human agent is supposed to perform
should be specified and implemented. Probably you know these checks
better than I do, so perhaps you could say whether it can be done.
> > > 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? :)
>
> Because, quite frankly, I have better things to do than hold your hand
> through complicated code and alogorithms that I have no guarantee you'll
> understand. You want to turn this into a contest of skill? Fine: look
> at the code, get out a pen and paper, work out what it does, verify its
> correctness of find a case where it is verifiably not correct, and
> provide some useful commentary.
No, I don't want to turn this into a contest of skill. But I guess
I said if you do I'll re-implement dpkg. :)
I looked at the code, but I've found out that it's not well commented.
Long-hacked C code isn't very easy to understand if there're no comments
around. I could work it out myself, but I'll be very pleased if you
could give a brief overview of the code and some useful comments because
I really want to do a review of the code. I guarantee that I'll understand
it. You could at least tell me about the algorithm that you used;
did you do random-restart hill climbing, or do you resort to a heuristics?
I'm pretty good at informed search algorithms, so I could help if
improvements are needed. IIRC, there are some new heuristics for SAT
and I could implement a new routine if the code turns out to have
time/space problems.
Brrr. I now looked at the code. That's why I haven't been writing C
for 3 1/2 years. cpp macros everywhere. nice coding, but a
lot of cryptic names and not too many comments. As I understand it
you're making a first-come heuristic to satisy dependencies, and
uninstall when installing things don't work... sorry, just too sleepy
something like that :/ It looks like you're exploiting the restricted-ness
of the dependency syntax, and ... this looks pretty much like an
informed search, but without counting how many clauses get satisfied.
Hmm. Why does it perform okay then?
May I kindly request you to tell me whether this search is complete?
And does it perform good because average |clauses|/|proposition_symbols|
is ... low? I'd be pleased if you can point out what to check next.
> If that's too much effort, go off somewhere and design and implement a
> useful set of tools for automatically testing packages, and come back
> with some examples of how well it works
No, that's not much effort. As you see I've already invested some
time in it. The code is okay as I've seen it; I assume you've already
benchmarked it so we could try to improve it if you've observed
performance flaws.
I suppose specifying a test-suite interface is enough. Something like
doc-base could be done also, perhaps.
> Now, just out of curiousity, what have you automated within Debian
> recently?
Nothing. Looking forward to this categorization thing, though.
> And in any event, tools don't have to make things more complicated. Just
> because we now have dpkg doesn't mean we have to use it for every new
> piece of software we install. Just because we have apt, doesn't mean we
> have to use it for every new piece of software we install. Just because
> we have bugscan, doesn't mean we have to use it as our sole measure
> of when we can release. Just because we have "testing" doesn't mean we
> can't manually play with what packages we will and won't release.
Why are we using apt in installing almost everything then? Anyway,
I think organizations like Debian should favor automated systems for
a political reason, too. It might be possible to distribute management
and provide less bureaucracy if you build it into the technology.
Less management, more equality. You don't have to agree with this,
but I have a feeling that many people here don't like bureaucracy.
> If using it will be so much easier than using dselect, then it'll be pretty
> easy for the layperson to judge it, won't it?
I think it should be. It's all about making it more intuitive, the
stuff to make it happen might have to be a bit complicated though.
[I'm not exactly sure at this point what kind of a hierarchy we should be
using. Though we discussed a good deal, and came to some preliminary
design]
> How's the phrase go? "Show us the code, or get out of the way". Something
> like that.
>
All right, you'll get some code. Not tomorrow, but later. ;)
About this dpkg.c thing, I've a lot of projects on my hand. :( The best
way would be to use a debugger to trace through that routine and
figure out exactly what it does (although I did have an idea what it was
when I read it) but that might take considerable time. Is there a
chance I could find a well commented version of that code?
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: