*.py packaging, again

Jeff Johnson n3npq at mac.com
Thu Jul 14 16:43:56 CEST 2011


On Jul 14, 2011, at 9:23 AM, Tomasz Pala wrote:

> On Thu, Jul 14, 2011 at 08:57:40 -0400, Jeff Johnson wrote:
> 
>> (aside)
>> Do you actually use repackaged packages? For what purpose?
> 
> Unfortunately yes, for restoring working set - too often...
> And during tests of course (various, like my private builds or bug
> hunting) [*].
> 

Well its *IS* you "unfortunate" choice to use --repackage (or not).
You have none but yourself to blame for your misfortunes.

Hint: Repackage packages were _DELIBERATELY_ poisoned by
adding RPMTAG_REMOVETID in order to prevent morons from
	install -> modify -> re-package -> re-publish -> blame @redhat
a *.rpm as if it were built "reproducibly" and "official".

Your "unfortunately" is likely mostly alleviated by simply
	Don't poison repackaged *.rpm by adding RPMTAG_REMOVETID.
I.e -- for most packages that are never ever modified --
you will find that repackaged *.rpm packages start to pass
	rpm -Kvv repackaged*.rpm
tests instantly.

There's little that can be done about modifications to %config
and the fundamental design flaw
	You can't repackage a file after "rm /path/to/file" has been done.

But that lack of functionality WILL give you years of RFE's and complaints:

	RPM sux because …

>> There are solutions here as well, depending on what is desired.
>> 
>> One can view side-effects like JIT'ed cached files as
>> either disposable and easily regenerated (in which case
>> the content should not be repackaged) or you can view
>> the JIT'ed cached files as stageful and persistent
>> (in which case repackaging should include the content).
> 
> I ask because I see that rpm stores original file list (with sizes and
> timestamps) in it's headers, regardless of actual content of cpio. It
> includes both modified and nonexistent files (especially %doc when excludedocs
> is set and ommitted %langs).

Not quite, --relocate stores both the original and the relocated paths.

And RPM uses cpio headers for exactly one purpose:

	The file path in the cpio header is used to locate the
	metadata in the RPM header.

> In this case cpio would contain more files than headers know about. What

And adding more files will fail to find _ALL_ information about
the added file, and the file will be skipped (iirc, been years, I fergit)

This is/was by intent: the advantage to RPM packaging is that _EVERYTHING_
necessary to perform an install is encapsulated in a digitally signed
blob that is essentially immutable. Any/all modifications to that blob
are detectable.

> might happen with recompilation on different timestamps during downgrade or some other
> weird operations like --noscripts?
> 

recompilation != immutable

And only immutable will do: there's lots of TOCTTOU issues with
rebuilding as well, honking about time stamps is a mere fig leaf.

> 
> *  I had an idea once upon a time to verify content of repackaged files
>   against original digest, I really miss this feature in rpm (rpm -Vp
>   verifies package against filesystem not internal cpio).
> 

Remove the RPMTAG_REMOVETID poisoning and repackaging (for most packages)
becomes an exact inverse and file digests can then be verified just
like any other package.

hth

73 de Jeff



More information about the pld-devel-en mailing list