Re: RFC: implementation of package pools
Jason Gunthorpe wrote:
>
> > I don't understand this. :) That's what tools are good for, being
> > 100% effective. We're not talking about group psychology here! It's
>
> If you don't understand this you need to spend some time researching
> computer reliability, and topics related to disaster recovery, fault
> tolerance, etc.
You can make a system very flexible and fault tolerant if you want to.
That's a matter of programming skill. Same as how your dollars don't get lost
at banks. Period.
> > But you don't manually intervene ld.so.cache, or do you?
>
> Again, that is a crazy example. ld.so.cache is not strictly required for
> the system to operate in a recovery situation and it can be completely
> reconstructed with a single program (so yes, you certainyl can intervene:
> rm /etc/ld.so.cache). None of these are true for the archive.
These are all true for the archive. Archive is just a set of files,
and all indices into the archive, auxiliary structures, etc. can be
reconstructed/repaired at any time.
The idea is to automate things. Automatons can be more reliable than
humans.
> > Yea, but if I can write a robust re-implementation of dpkg that's
> > at least as reliable as the text-based one, and which has enough
> > utilities that make it as convenient as editing text files with
>
> Again, you appear to have no understanding at all on how software systems
> fail. If you were to make all binary tools, and make them so they could
> compensate for all possible failure modes on the binary database you would
> have a system that is a magnitude more complicated than it really needs to
> be. Human intervention is an acceptable recovery procedure for /var/lib/dpkg.
>
It will be a magnitude more complicated (correct) and a magnitude
more efficient, and at the same time be more reliable. How about that?
It's a shame that any internal structure needs to be repaired manually
in any written program.
I told you that it's a matter of programming skill. I can fix the
current dpkg so that it transparently does _everything_ you guys can do to
recover from failures. It would be a waste of time, though because those
methods would also work with a more efficient version.
If you turn this to a test of skill, I will do it ;)
> The author(s) will package them and upload them. Anyone uploading code
> from their CVS trees would be doing a serious breach of protocol.
What breach of protocol are you talking about? If they're delaying
a package, then someone else can surely do it. Or aren't they using
a DFSG compliant license? If they aren't I think this means serious
trouble. :< I insist that every package should have an ITP. This is
a more important thing than any of the stuff discussed here. [certain
design decisions for _an_ implementation of package pools]
Thanks,
--
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: