Re: RFC: implementation of package pools
Previously Eray Ozkural wrote:
> 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.
Perhaps you misunderstand the concept if this thing called `unstable'.
It's mean to be *unstable*: the more that breaks there the better it is
since it means we will notice and fix it.
What you are looking for is more like `testing' which Anthony Towns
is working on. But the difference between testing and unstable is
completely orthogonal to the underlying technology used to manage
the archives, ie the old dinstall or the new package pools based
dinstall.
> I'm sure that major OS vendors have been using these procedures for many
> years.
Haha, try and find any other OS vendor that works in the same way as
Debian.
> I think a symlink-farm is considerable because of its intuitive appeal
> to potential mirror and CD makers.
Partial mirroring would be the only reason, special mirroring tools
will probably needed.
> Why haven't they been able to fix it for years then?
Do you have any idea what the complexity of a solid filesystem are?
Have you ever designed and implemented a filesystem that is as stable
as ext2 is?
> 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.
Oh come on, this has to be the most stupid remark I've seen in ages.
I don't think I've ever seen anyone who gets more work done then Alan Cox.
Linus might do less work (I don't have a very good view on the amount
of work he does), but you will have to admit that he has done an
excellent work on keeping people working together and maintaining a
stable kernel.
> 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.
I'm offended that you so easily say that it's crap and you can single
handedly do better. As you yourself said, show us the work done and
we'll talk again.
> All right, so you're also the author of that checkinstallable routine.
Have I ever claimed that? No. Please keep your facts straight. Judging
by your remarks I have a better graps of what it does then you do.
> 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.
As I said, don't even bother to try to convince me that is true.
> 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...
Good for you; more people should do that.
> 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.
What is g++ code?
> * both non-terminal and terminal symbols have their classes. exploit
> inheritance, information hiding, etc.
> * uses standard C++ for efficiency and very comprehensible code.
standard C++ does not mean better efficiency or more comprehensible
code. I fact it's much easier to write crap C++ then it is to write
crap C code.
> downsides:
> * syntax not extensible at run-time. something bison lacks, too.
Shouldn't be very hard to add that even.. those tables can be
(re)generated easily.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| wichert@cistron.nl http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Reply to: