Upcoming changes (in 1.4.1)

[Jeff Johnson]

On Aug 20, 2011, at 12:39 PM, Anders F Björklund wrote:

> Jeff Johnson:
> 
>>> Currently these are getting set, when installing:
>>> Packageorigin: /var/lib/smart/packages/*.rpm
>> 
>> Is that literally a '*" or just that all origins are of that form?
>> Presumably no "*" is present …
> 
> Of that form, sorry. Whatever the original filename was.
> It's RPM itself setting it, when given a file I think ?
> 
>>> Packagestat: <struct stat, of the above file> 
>> 
>> This is set when the FD_t is opened, either by Stat
>> (or more typically of bindings) by Fstat through fdDup().
> 
> Yes, smart does a "h = ts.hdrFromFdno(fd)" to get it...
> (after doing a "fd = os.open(path, os.O_RDONLY)" first)
> 

There are other methods that verify the integrity that
have existed since forever … and they aren't slow.

(aside_
I suppose the only way to *force* the port is to rip
the ancient baggage out of rpm-python. todo++.

>>> 
>>> That origin path is to the (temporary) location,
>>> which will (by default) be removed after install.
>>> Not sure why the digest isn't being set (by rpm) ?
>> 
>> The goal is to get the tag populated with *something*,
>> even the temporary location already indicates what depsolver
>> was used to install a particular package.
>> 
>> The digest can't be set unless computed. This
>> would force a read-compute-rewind cycle that
>> prevents streaming a package straight off
>> a pipe or socket (which forces caching and cleanup etc etc).
> 
> Ah, right. Figured it was something like that...
> Anyway, those two values was just what rpm did.
> 

Yes rpm is *already* trying to populate those tags
transparently. A little help please was the nature
of the RFE for smart ...

> It seems like both the original URL and the file
> digest(s) needs to be propagated from the fetcher ?
> 

That is indeed what the intent was and is: "propagation".

>>> 
>>> Anyway, not enough information to regenerate md…
>>> 
>> 
>> Is smart ever verifying the file digest?
>> 
>> If the file digest is being verified, then adding that
>> to the header would indicate that the file digest was locally computed.
> 
> Smart does verify the file digest(s), but only as part of
> the downloading. The installation is done from local files.
> 
>> Otherwise, just calling with the repo-md file digest is
>> about as good as its gonna get: at least the sewage
>> can be regenerated with the same value as initially
>> present.
>> 
>> rpm doesn't read repo-md sewage and can't easily find file
>> digest.
> 
> Both the original URL and the file digest *should* be
> available, just that they aren't with the current API.
> 

Understood.

> A slight issue is that there are multiple urls and
> multiple digests, but I guess any of those would do ?
> 

The url/digest that was actually used is preferred. But
I'll take anything -- including "FIXME" -- to start populating
those tags reliably.

73 de Jeff