Software Management call for RFEs

seth vidal skvidal at
Tue May 28 15:51:21 UTC 2013

On Tue, 28 May 2013 08:51:03 +0200
Jan Zelený <jzeleny at> wrote:

> > after a "yum clean metadata && yum update" on a slow line you
> > have to wait a very long time and even the download of the
> > presto-metadata often is larger and takes longer as the
> > packages which are updated in reality
> > 
> > hey on my 100 Mbit all is nice and fine but on a machine behind
> > DSL with around 100 KB/Second it is way too slow and large and
> > i refuse to imagine how this feels on a 56kbit modem
> I couldn't agree more. But as I have said, we need to find the most
> simple and unintrusive things that can be done to improve this. For
> instance: file lists take a considerable portion of the entire
> metadata size. But if we were to remove them, things like "yum
> install /usr/bin/vim" would not work any more. And you get similar
> scenario with almost all the metadata that we store - we store them
> for a reason and without them some things that people use will not
> work.

 the above is not correct.
Files in *bin/* are in the primary metadata - not in the filelists.
That was specifically designed to handle the 90% of file-deps which are
*bin/* or /etc/*. It's not accidental.

so if you nuked filelists entirely you'd only lose people who have
filedeps on something outside of those wildcards above. I've spent
HERCULEAN amounts of effort to whittle down the set of filedeps outside
of that area. I filed hundreds of bugs on the subject in years passed.
I simply got tired of tilting at that particular windmill when
confronted with some particularly egregious cases (see libguestfs

But it is absolutely NOT TRUE that removing filelists will cause 'yum
install /usr/bin/vim' to not work.

If you have further questions about how the metadata works or was
designed please feel free to ask me, directly. I believe I and Adrian
Likins are the only current Red Hat Employees or Fedora Contributors
who were present/involved in its original 'design'. Such as it was.

It might prove helpful to know that background to avoid walking down
blindalleys in DNF.


More information about the devel mailing list