Re: RFC: implementation of package pools
Previously Eray Ozkural 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.
You gravely misunderstand what this is about: this is the technology
to manage the archive, not do things like testing. That should be
a layer on top of this.
> distribution symlink-farms. ie, your testing becomes just a symlink
> farm into the pool.
You don't need the symlink farm since the path to the package is
inside the Packages file.
> 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're even more arrogant. They know perfectly well what the good
and bad things are about ext2.
> I looked at that, but why do I have to find what's hidden? :)
> It's about Depends: and Conflicts: things right? :) Whatever.
> 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. ]
Hahaha! Trust me, i've been in a CS dept for 7 years now and I've seen
people get their msc without knowing anything about satisfiability
problems. And no, that's not just true for this university,
unfortunately that happens everywhere. (no need to try and convince me
your university is different)
> 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. :(
Probably because bison uses good algorithms.
/ Generally uninteresting signature - ignore at your convenience \
| email@example.com http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |