On Sun, Oct 22, 2000 at 10:44:07AM +0300, Eray Ozkural wrote:
> 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.
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.
Of course it supports upload and removal of packages from the pool. That's
it's whole point.
> > 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.
No, it's not even that. The Packages and Sources files alone are enough.
I'm sure I explained this previously.
> > 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.
Now compare and contrast Linux with all the advanced research OSes out
there that do use all these great features. Consider why Linux is well
known as a useful and reliable system, and the other's aren't.
> Think gcc, and say that again. [uses a lot of optimization algorithms
> from research. so?]
I'm not well grounded enough in either the gcc code base or compiler
research to comment.
> > 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.
As opposed to "Linux sucks. Respect my academic authoritah, damn you!"
or whatever all this hot air amounts to.
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.
Or go off and write some papers about all this that some of us will read
in a decade or two and implement when we need it. Or whatever.
> > 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?
Yes, I'm sure. Now try giving the problem some thought, and see if you
can work out why you might need the full SAT. It's really quite a trivial
proof.
> Why do you assume that I don't know about satisfiability problem? I'm
Stop trying to take offence at everything.
> > 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?"
You're not even stopping to think are you?
The people you're responding to in this thread are:
Jason Gunthorpe: the guy who wrote a tool to automate the
selection of new packages, their downloading and their
ordering
Wichert Akkerman: the guy who's currently maintaining both the
automated list of things left to do for the next release,
and the tool that automates installation and removal of
just about every file on your system
and myself: the guy who's major interest in the subject of
this thread is as infrastructure for his own tool to
automate winnowing out the buggy packages that might
get uploaded
Now, just out of curiousity, what have you automated within Debian
recently?
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.
> > 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? [...]
> [...] Using it will be certainly easier than using dselect!
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?
How's the phrase go? "Show us the code, or get out of the way". Something
like that.
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:
pgpdAAsBLv9yR.pgp
Description: PGP signature