Dne Út 28. května 2013 11:51:21, seth vidal napsal(a): > On Tue, 28 May 2013 08:51:03 +0200 > > Jan Zelený <jzeleny@xxxxxxxxxx> 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. > > Jan, > 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 > sometime). > > > 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. I knew there were some optimizations in the filelist case, I just wasn't completely sure what exactly would cause downloads of the filelist. Anyway, thanks for the explanation Jan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel