> Can you point me to the primary.xml -> SQLite translation in yum? I've
> got a fairly efficient primary.xml parser.
Just set mddownloadpolicy=xml in yum.conf. It should work, but
since downloading sqlite.bz2 is much better, very few use this.
Yum uses fairly efficient parser, written in C, usi
> And there package diffs, which are ed-style diffs of the
> Packages file I mentioned above. This approach would work quite well
> for primary.xml because it doesn't contain cross-references between
> packages using non-natural keys. It doesn't work for the SQLite
> database, either in binary or
Hi,
People were complaining that yum autocompletion of package names
is very slow (Bug 919852). Now there's a shortcut that (if enabled)
makes it much faster. However, the behavior changes slightly:
- disabled but cached repositories are used
- configured package excludes are not honored
- all
> /pub/fedora/linux/updates/17/x86_64/repodata/34881e74623de1754bf0e12f01884bea615fdcee05eded189f22d41bf9d4260b-other.sqlite.bz2
>
> That file no longer exists; it was on my mirror from 21:12 Monday to
> 22:17 Tuesday.
>
> I'm guessing there's either a yum bug or a
> broken repo push that is:
>
>
> This is what I get for the last few days:
> # yum --skip-broken update
This is a fairly common scenario. Let me explain..
Repository cachecookie was older than 6 hours,
Yum updates the metalink.xml file:
> updates/17/x86_64/metalink | 16 kB 00:00
The repomd.xml timestamp stored in metal
On Wed Sep 26 08:02:05, Reindl Harald wrote:
> yes, and that is why statistics of mirrors are meaningsless
> because of this fact my idea to give us a config-option
> "dear yum, if the selected mirror provides lower than
> 500 KB/sek try another one because my line can 12 MB/sec"
FWIW, we've incr
> From: "Nicolas Mailhot"
> can we get a package downloader that sends the correct
> cache-control http headers to refresh data automatically
> instead of complaining metadata is wrong and aborting
> (for people behind a caching proxy)?
Have you tried changing http_caching option in yum.conf
fro
> I'd be happy if yum/urlgrabber/libcurl finally used http keepalives.
It does, indeed. Parallel downloader tries to use keepalives, too.
(we cache and reuse the last idle process instead of closing it)
> Last time I looked (and it has been a while), it didn't, so you
> always paid the TCP slow s
> The number of concurrent users is now lower because, well, each of
> them now completes a "yum update" in one third of the time.
I think Glen's concerns were that the consumed resources
(flow caches, TCP hash entries, sockets) may scale faster
than the aggregated downloading speed.
I am aware o
Hi Glen,
> Why is the default three connections rather than one? Is a tripling
> of the number of connections to a mirror on a Fedora release day
> desirable?
$ grep maxconnections /var/cache/yum/*/metalink.xml
/var/cache/yum/fedora/metalink.xml:
/var/cache/yum/updates/metalink.xml:
> So disable fastestmirror plugin before testing this,
> would be the way to go?
The fastestmirror plugin does some initial mirror sorting.
We mostly ignore this, so disabling fastestmirror makes sense
but is not strictly necessary.
--
Zdeněk Pavlas
--
devel mailing list
devel@lists.fedoraproj
> > Both packages are compatible with older versions.
>
> Can we use them in Fedora 17 too ?
Yes, I've used it in F14 for some time.
--
Zdeněk Pavlas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hi,
A new yum and urlgrabber packages have just hit Rawhide. These releases
include some new features, including parallel downloading of packages and
metadata, and a new mirror selection code. As we plan to include these
features in RHEL7, I welcome any feedback or bug reports!
python-urlgrabbe
13 matches
Mail list logo
