On Sat, 2003-11-01 at 08:19, Josko Plazonic wrote: > 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. > yes. there is. You have the metadata in one set of files and the complete file lists for that 5% of packages that have a file requires that is not a file caught by the wildcards *bin/*, /etc/* or /usr/lib/sendmail. > 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). people have requested "show me all packages changed in the last N days" or "show me the changelogs from this update to a program" > 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). no you don't. You need to make sure you're not leaving a corrupt header. and just b/c the version didn't change doesn't mean the package didn't. > 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. why do it w/o being asked? > 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. I think it will help that problem significantly. -sv
