[Yum] Using hdlist and some questions

[Josko Plazonic]

seth vidal wrote:

>The biggest problem with focusing support on the hdlist is that the
>mechanism of using the header is going away in a future version of yum.
>Instead of using the headers to figure out which packages we'll need we
>use the metadata from the header to figure out which packages to try to
>test with then we only download the header when we've got a greater
>likelihood of needing it - for the transaction set check. 
>  
>
Careful there, while it is going to work in most cases you are going to 
have problems with certain dependencies, at least as they are configured 
now, especially where one package needs a file and another provides it - 
no way to know which rpms are involved without having all the header data.

>3. I've honestly never liked the hdlist mechanism b/c it seems like a
>kinda kludgy way of collapsing the headers, added to it that they don't
>contain all the information, so supporting this then implementing things
>like 'changelog query' is quite hard b/c last time I checked the
>changelogs just aren't there - nor are the complete file data, iirc.
>  
>
I think the only thing missing are changelogs, check the patch better - 
you need to invoke a special function in order to get file data before 
writing the header out to disk. I personally don't see why query 
changelogs anyway but maybe that's just me (too much stray data in there).

>only for the packages in the core distro, not for secondary
>repositories.
>  
>
Exactly, usually it is also the most important one and the one that upon 
first yum run the most data will be downloaded from.

>it does that to ease rsyncing of the hdrs on remote repositories.
>look back in the archives, there was a fair bit of gnashing of teeth
>about this in the past.
>  
>
Can be solved also by updating only what's necessary, but I do see this 
is an easier workaround.

>two reads (header and rpm, then compare) and a write (header) or 1 read
>(rpm) and a write (header).
>  
>
Maybe is more efficient (though why reread headers, all you need to read 
is header.info - then it is read all rpms, read headers.info, write only 
headers that changed).

>If you've not asked it to do something why do it?
>  
>
Makes sense?  I think it should be the default in install/update cases - 
why keep a header for a package that's just been installed. 

> And thanks for the patches, I don't think I'll include them, though,
>b/c I'm not sure it's a longterm benefit.
>
>Does that make sense?
>  
>
Fine with me (perfectly capable of patching stuff myself), I hope the 
new way of downloading headers will in near future solve my concerns 
anyway.  I mostly want with this to eliminate the initial download from 
the core repository.

Josko