radical suggestion for fc4 release

[Nils Philippsen]

On Wed, 2005-02-02 at 17:07 -0500, Jeff Johnson wrote:
> Nils Philippsen wrote:
[...]
> >I'm fully aware of that this would need serious work and likely
> >incompatible changes to the RPM DB. You can easily reconstruct that
> >single blob as it is now from a split header + changelog and verify the
> >resulting blob against the signature/digest.

Apologies for not labeling my posts "theoretical musings about how
changelogs could be made less redundant in the DB".

> You cannot reconstruct from missing information at all.

If the header is now (everything else + changelog) and changelog gets
split out I don't see how there is any missing information -- you just
grab "everything else" and the changelog and have your blob again.

> Splitting information between package header and Something Else Instead
> is a rather awkward verify to develop trust in.

If it were done (note the use of the subjunctive, theoretical discussion
and all that) it would obviously have to be a two-way unique mapping
from single blob to header plus split out redundant data (let's not talk
about the changelog, as this only distracts) and vice versa.

> Adding changelogs outside of packages is what was suggested, and removing
> or at least truncating, changelogs too. Either is trivially done, and 
> requires zero changes to existing rpm or rpmdb.

Agreed, but I guess the opinions on whether this is desirable or not
differ quite dramatically. On the one hand there's the "remove unneeded
cruft" argument and on the other the "I might need just that bit of info
when I'm cut off the net". I guess we won't bring these two together
unless there is an easy way to take the changelogs with you when doing
an "offline" job and to easily get the right changelog for the packages
taken with you, i.e. verification that this changelog belongs to that
package would also need to be thought about.

> Or add changelogs to specspo, as that has been needed quite some time 
> now, so that developers can describe changes in their native language.

Hmm. If you have one isolated developer, then yes. But if you have
multiple people working on one package, it will (sensibly) lead to the
common denominator being used (which is English) as it is done with
string to be translated in applications.

> Only your blind expectation that packages contain changelogs forevermore is
> is preventing you from seeing the simplicity of it all imho.

As outlined above, your simplicity for rpm and rpmdb is bought by
complication elsewhere. Not that that'd necessarily be a bad thing ;-).

> But, presumably, you are fully aware of that too. RFE in bugzilla to start
> getting your changes to RPMDB to normalize changelogs on installed client
> machines properly prioritized please.,

Hey, don't take it personal, it's only a theoretical discussion from my
side, which I should have said before. Sorry.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011