Re: perl breakage in Cooker mostly resolved

On Jan 20, 2012, at 3:26 PM, Jeffrey Johnson wrote:

> 
> (for extra credit)
> There is an additional technique that permits curried plain texts to be chained
> (and not only with symbols) that is useful for pinning down exactly what broke
> that is also going to be needed for the technique I mentioned to be deployed.
> 
> Lets say you split the huge list of perl symbols into a "core" and a "extension"
> set.
> 
> Each of "core" and "extension" will then have its own digest.
> 
> The chaining comes from having a meta-plaintext composed of 2 lines
> (for my artificial example) that would look like
> 	core		<core-digest-here>
> 	extension	<extension-digest-here>
> 
> And that 2-line file is also digested (and included somehow with packaging).
> 
> Then when the
> 	Requires: perl(abi) = <meta-plaintext-digest-here>
> "breaks" (as it inevitably will), then the actual plaintext is retrieved to
> identify whether "core" or "extension" symbols were changed.
> 
> The above is an entirely artificial example used to illustrate the chaining.
> 

For pedantic purposes, what I am calling "chaining" is nothing
more than a hash or Merkle tree (see wikipedia).

The important point relevant to *.rpm packaging and automating
dependencies, is that MUST be some way for humans to diagnose
the failures: its the attachment of the "core" and "extension"
labels that is needed.

Once can of course extend the chaining generally so that each
symbol (or more generally every state change in the plaintext)
can be identified precisely by recursion through the plaintext.

Note that the above is "overkill" only in the sense that dependencies
automated like this have a complexity/obscurity that would
challenge any human to "fix".

But the algorithms and tools needed aren't particularly hard
to code up even if every single symbol in every single
executable needed to be added into a hash tree.

I am assuming a persistent distributed store is available when
debugging a broken automated dependency.

Hint: the mongo-c-driver is bundled into rpm-5.3 for a reason.

I'm also assuming that there is some serious interest in
improving the quality of a Mandriva/ROSA distribution by
applying better automation methodically to packaging
processes.

And please note that I heartily agree "overkill" because
of the inertia changing Linux packaging processes meaningfully.

But the "proof is in the pudding": computers make wonderful
automatons without any need to discuss, say, urpmi dependency
breakage on this mailing list.

I expect some scheme like I just outlined to be proposed
for package management in the next few years.

I'm merely waiting for someone else to go first so that @rpm5.org
can follow as second: I have no desire to advocate any change
whatsoever to Linux packaging and RPM.

Perhaps its time for "anonymous" to add an entry to @rpm.org trac
or to propose the above to Debian.

todo++

73 de Jeff