Re: RFC: implementation of package pools
Wichert Akkerman wrote:
> 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.
>
Are you sure of this? You can put more relaxed tests for unstable
than for a more stable release tree.
I think that if you could prevent at least some of the high-severity
bugs with an automated test suite, it would be a win. Not a loss.
Also it's more suitable for dog-food practice, because I suspect
that many developers won't be using unstable themselves for potential
nasty breakages (remote printing hadn't worked on my system for more
than 6 months)
An intermediate release, called "development" or "testing" or whatever
name is appropriate, would apply stricter tests. Stable gets even
crazier tests including security tests emulating known net attacks,
etc. Of course some of this vision might be difficult to implement,
but it sounds reasonable I guess.
> 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.
With the kind of testing I suggest, it isn't.
>
> Haha, try and find any other OS vendor that works in the same way as
> Debian.
>
I bet there are some that does the testing like I describe, for instance
in Microsoft people write test suites properly[1]. No one of course is
as effective as Debian, because in Debian work is well distributed especially
in case of bug fixes. The modularity is done right to a large extent, etc.
But another success of Debian is I think in the success of "glue" software.
I propose that bug-finding and package checking gets some more "glue"
software and gets more automated so that developers run into less trouble.
> Partial mirroring would be the only reason, special mirroring tools
> will probably needed.
>
Yeah, that's what I thought. It would encourage people to mirror a single
release.
> 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?
>
I have the ideas, but I haven't implemented a filesystem as stable
as ext2. I would be very interested in writing one of course. I recently
read a lot of distributed OS papers, and it really seems a very nice
subject to work on.
> 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.
It is a stupid remark in the respect that you emphasize. Alan Cox is
my favorite linux hacker. But Linus seems to hold the ropes... Something
smelling there.
> 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.
His work was described as "floating over cries ..... like a dictator"
>
> > 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.
No, I don't intend to write a replacement for ext2fs. There're already
some excited hackers that want to do that. :) I'm very curious about
the results (like reiserfs going into 2.4, etc)
>
> > 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.
Didn't you see the *<:) at the end of "I didn't know you were the author
of ext2fs"? Just another joke. Take it easy. I like inserting jokes in a
random fashion. :)
I'm hoping that you're familiar with the code, though. Some questions
at the end of this mail.
> > It does have nice properties though.
> > * g++ code, use directly in your c++ proggy.
>
> What is g++ code?
code that works with g++. it isn't bug compatible
with any other odd compiler :)
> > * 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.
If you use it the correct way then it does. Many people haven't yet
examined the final ISO standard, if it wasn't that useful g++ team
wouldn't be working so hard on getting standard compliance right.
>
> > 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.
Yeah, but it's not about tables. Important part of the semantics go
in the compile time (something not possible in C) in my framework, and
I don't want to add an auxiliary object system for run-time
classes. I think that's a very bad programming practice (something
like the stuff in GTK, or MFC's runtime classes). I usually program
with: only a single object system. BTW, I'm not saying that GTK
is programmed badly, it's the only way to do it in C. I'm referring
to the runtime object system it uses. Languages that support OO
paradigm give you a class system, so if you use another object
system which you have implemented there will be a lot of trouble
mapping it to the language's native object system. That's why stuff
like COM comes with a price, if you're using C++ you'd better
be using its class construct, not re-invent the wheel. Anyway.
----
You haven't answered to my request on the dpkg.c Could you please
give a brief overview of the code and algorithm used for satisfaction
in checkinstallable? I'd really like to review it and contribute
to the code. Is there a well commented version of it somewhere?
Sincerely,
[1] I say nothing about the quality of their OS, don't flame me.
--
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: