So i'm for killing hdlist.cz regenerating all the time one hdlists.cz which is more that 70MiB is a reall overkill.
2014-04-01 4:49 GMT+02:00 Rolf Pedersen <[email protected]>: > Sorry, I realized I was doing my urpm* testing in Rosa 2012.1 > In OMV 2013.0, I'm finding that, with global policy set to Always and a > freshly-updated info from MandrivaUpdate, urpmf is very fast. Also, booted > back to Rosa, it is now fast, also. My longest waits, previously, were > when I was searching for a file that was not in the distro, so a list from > each repository was downloaded. It appears, with Always configured, some > stale lists are being refreshed when some strange string is given. > Eventually, a nonsense word returns no match quite quickly, without any > downloading. So, as it is, xml files are working just fine for these uses > for me, with Always set, it seems. > Thanks, > Rolf > > > On 03/31/2014 06:30 AM, Denis Silakov wrote: > >> Ok, thanks a lot for the info. >> >> So at least handling of xml files can be improved. >> >> As for dropping their generation - actually this won't save much >> time/space, unlike hdlist.cz. >> >> On 03/31/2014 05:27 PM, Rolf Pedersen wrote: >> >>> >>> On 03/31/2014 01:02 AM, Denis Silakov wrote: >>> >>>> Hi all, >>>> >>>> As many of you can likely notice, package publishing in ABF usually >>>> takes relatively significant time - about several minutes (sometimes up to >>>> 10 minutes). >>>> >>>> One of the time-consuming tasks in the publishing is generation of >>>> hdlist.cz file - this is a huge file containing internal urpm >>>> representation of metadata, including file lists, package descriptions, >>>> etc. This file seems to be redundant - nowadays we generate additional xml >>>> files (changelog.xml, info.xml, etc.) which in combination with lightweight >>>> synthesis.hdlist.cz provide the same information. However, I am not so >>>> familiar with hdlist.cz and can't guarantee that nothing will be lost >>>> if we completely drop it. >>>> >>>> So the question is - can somebody say what will we lost (if any) if we >>>> drop hdlist.cz files? Or maybe we should just try and see? >>>> >>>> Hi, >>> I hope someone can make some sense of my experience wrt hdlist.cz etc. >>> Many years ago, iirc, synthesis.hdlist.cz was introduced as an >>> optional source of media info that could be chosen by those with a slow >>> internet connection, as it was smaller and took less time to download than >>> the traditional, default hdlist.cz. I always chose hdlist.cz as my >>> connection was relatively quick and, I think, there was more information >>> included, naturally. Also, whenever I used urpmq/urpmf to query the >>> database, which is my primary usage of this important tool for >>> investigating packages capabilities, the result was almost immediate, >>> since the data was already on my computer. At some point, hdlist.czwas no >>> longer available as a way to configure urpmi. Every time I search >>> for a package containing a file of interest, I have to wait a long time for >>> xml files to be downloaded from each media source. Also, when I look for a >>> changelog in MandrivaUpdate or with urpmq, it must be retrieved. IIANM, >>> the package info would already be available on my machine when using >>> hdlist.cz as urpmi.update had already been done. Admittedly, this is >>> an accounting of the events of a number of years that is challenging for an >>> aged memory, but my recollected experience is that the functionality of >>> urpm was better with hdlist.cz than with anything that has come since. >>> Maybe generation of the others could be dropped to gain publishing speed? >>> :) Alternately, perhaps an option could be provided where all the current >>> information is downloaded when urpmi.update is run and/or with CL switches. >>> >>> ^^^Those words reminded me of the policy option to Always download xml >>> information in the rpmdrake media manager, which I recall trying, before, >>> without improvement. I see this in the urpmi.cfg manual about global >>> options: >>> >>> xml-info >>> For remote media, specify when files.xml.lzma, >>> changelog.xml.lzma and info.xml.lzma are downloaded: >>> >>> never >>> on-demand >>> (This is the default). >>> >>> The specific xml info file is downloaded when >>> urpmq/urpmf/rpmdrake ask for it. urpmi.update will remove >>> outdated xml info file. >>> >>> nb: if urpmq/urpmf/rpmdrake is not run by root, the xml >>> info file is downloaded into /tmp/.urpmi-<uid>/ >>> >>> update-only >>> urpmi.update will update xml info files already required >>> at least once by urpmq/urpmf/rpmdrake. >>> >>> nb: with update-only, urpmi.update will not update >>> /tmp/.urpmi-<uid>/ xml info files >>> >>> always >>> all xml info files are downloaded when doing >>> urpmi.addmedia and urpmi.update >>> >>> I checked and no global policy was defined, so I set it to Always in >>> media manager, which is reflected, now, in urpmi.cfg: >>> >>> { >>> downloader: curl >>> verify-rpm: 1 >>> xml-info: always >>> } >>> >>> This stanza was empty, before, by default, I guess. I then ran a urpmf >>> query and watched as xml files began to be downloaded, so I quit. This is >>> what I recall of my previous attempt(s) to replicate the hdlist.czbehavior. >>> Just in case, I ran urpmi.update (as root), followed by urpmf >>> (as user). The following lists were all downloaded before the query >>> finished: >>> >>> http://mirror.rosalab.ru/rosa/rosa2012.1/repository/x86_64/ >>> media/main/updates/media_info/files.xml.lzma >>> http://mirror.rosalab.ru/rosa/rosa2012.1/repository/i586/ >>> media/main/updates/media_info/files.xml.lzma >>> http://mirror.rosalab.ru/rosa/rosa2012.1/repository/x86_64/ >>> media/non-free/updates/media_info/files.xml.lzma >>> http://mirror.rosalab.ru/rosa/rosa2012.1/repository/i586/ >>> media/non-free/updates/media_info/files.xml.lzma >>> http://mirror.rosalab.ru/rosa/rosa2012.1/repository/x86_64/ >>> media/restricted/updates/media_info/files.xml.lzma >>> http://mirror.rosalab.ru/rosa/rosa2012.1/repository/i586/ >>> media/restricted/updates/media_info/files.xml.lzma >>> >>> A urpmq --changelog query is quicker, since urpmi knows where the single >>> package comes from, but that sources changelog.xml.lzma is still >>> downloaded, even after the previous configurations, whereas the old >>> behavior with hdlist.cz was to immediately use the info on the >>> computer. As I say, my accounting might be distorted by misunderstanding, >>> time, or nostalgic prejudices but that's my story and I'm sticking to it! >>> Thanks, >>> Rolf >>> >>> >> >> > >
