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