So i'm for killing hdlist.cz <http://hdlist.cz> regenerating all the
time one hdlists.cz <http://hdlists.cz> which is more that 70MiB is a
reall overkill.
2014-04-01 4:49 GMT+02:00 Rolf Pedersen <rolfpeder...@mindspring.com
<mailto:rolfpeder...@mindspring.com>>:
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 <http://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 <http://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
<http://synthesis.hdlist.cz> provide the same
information. However, I am not so familiar with
hdlist.cz <http://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 <http://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 <http://hdlist.cz> etc. Many years ago, iirc,
synthesis.hdlist.cz <http://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 <http://hdlist.cz>. I
always chose hdlist.cz <http://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.cz
<http://hdlist.cz> was 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 <http://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
<http://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.cz
<http://hdlist.cz> behavior. 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 <http://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
