On 28.05.2013 18:51, seth vidal wrote:
On Tue, 28 May 2013 08:51:03 +0200
Jan Zelený <jzel...@redhat.com> 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).
I just tested on a F18 box the following:
yum erase -y datalog
yum clean all
yum install sqlite-datalog #3 non-existing package
yum install -y /usr/bin/datalog
In the above sequence, yum do not downloaded the filelists at all.
yum erase -y datalog
yum clean all
yum install sqlite-datalog #3 non-existing package
yum install -y /usr/share/lua/5.1/datalog.lua #4
In the second sequence, yum started the filelists downloading at #4.
So, it seems that yum already have the "filelists on demand"
optimization implemented. Why you are asking for removing a feature,
which do not make the things worse ... ?
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.
I have a few questions:
* What is the reasoning behind the splitting of the database across
many .sqlite files?
* Why the sql schema is so denormalized (IMO, leads to both bandwidth
and disk overspending without speed benefits)?. For example: Why
provides and requires tables do not use the common domain table?
* Why the incremental update mechanism (eg. applying xml diffs to the
sqlite database) was not been considered from the very beginning?
Thanks!
Alek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
