Re: RFC: implementation of package pools
Wichert Akkerman wrote:
>
> 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.
>
Are you sure? As far as I've seen, things including the recent libc
breakage could be avoided if there was a testsuite that ran automatically
_before_ packages got uploaded. For instance, exim is considered
to be an important subsystem, when libc6 is to be checked for
upload all packages dependent on it have their test suites run... In
such a case, exim would fail the testsuite, indicating that a breakage
would be expected.. and consequently the system would decline upload
of that package. I'm sure that major OS vendors have been using these
procedures for many years. It's a sound software engineering practice.
This doesn't seem to be a layer on top of the archive. It seems
to be another module that is directly invoked from the archive manager.
I'm awating for your comments.
> You don't need the symlink farm since the path to the package is
> inside the Packages file.
I think a symlink-farm is considerable because of its intuitive appeal
to potential mirror and CD makers. As I've said I favor automated
systems more. If you can provide stable mirroring and browsing tools
for differing distributions (and other things a symlink-farm would
ease), it's okay.
> > 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.
Why haven't they been able to fix it for years then? Anyway, if you
find me arrogant, it's okay. But everybody on that list seems to
be a fan of Linus and Alan, a repulsive circumstance for any new
linux developer. It's like a strict hiearchy, very different from
what goes on in the GNU project where people favor work done instead
of reputation.
I didn't know you were the author of ext2fs *<:) I don't see why
you're offended by my reaction to ext2fs when given as an example
for good software.
[checkinstallable]
> It's not.
>
All right, so you're also the author of that checkinstallable routine.
Will you please be kind enough to provide me with some comments on
that code? It's not well commented. I was asked to do a peer review
of the algorithm, so I'd be very glad to have that information.
> 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)
No, my university isn't very different. Individuals might be differing,
though. At any rate, every CS grad. who's dealt with logic would've
known it. I'm a SIGART member, so I'm dealing with AI as a hobby.
Perhaps that's why I'd read our textbooks more carefully and read a lot
of extra books and taken courses on semantics, proof nets, etc...
If that code can be improved with any chance, I'd like to contribute
to it. I'm well versed in informed search, so I might be of utility
here.
> > 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.
Now you're arrogant. And you're doing a biased interpretation of
my sentence :) I said it's not better than bison. This doesn't imply
that bison is better than my parser. It's just that my parser framework
isn't so much better than bison generated parsers.
It does have nice properties though.
* g++ code, use directly in your c++ proggy.
* both non-terminal and terminal symbols have their classes. exploit
inheritance, information hiding, etc.
* uses standard C++ for efficiency and very comprehensible code.
* same performance as bison code. [we're all implementing the
stuff from red dragon book anyway!]
downsides:
* syntax not extensible at run-time. something bison lacks, too.
I was writing a small pascal compiler with it, but I abandoned the
project because I wanted to go at a lexical analyzer first. [which
I hadn't solved as good as the LALR parser] I never released it, but
if there is anyone writing large compilers, the design will be
very interesting to them. [ I personally didn't use it for a small
code gen. project and simply used flex/bison. ]
Sincerely,
--
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: