On 28.05.2013 13:54, Jan Zelený wrote:
On 28. 5. 2013 at 11:39:35, Alek Paunov wrote:
On 28.05.2013 09:51, Jan Zelený wrote:
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.
Not so unintrusive, but would it be acceptable if we merge all .sqlite
DBs from all repos in a single .sqlite with tree-like schema? Let say we
achieve overall size reduction by factor of 4, at the price of more
complicated but faster SQL queries. [I hope that such a change will also
make the incremental by the XML sources easier]
I am going to experiment this, if make sense ...
Perhaps it's just that I don't fully understand your vision but I'm not sure
that's a feasible solution. How exactly would you solve the fact that users
have different repos enabled on their machines?
Or did you mean merging them on the client side? That would not solve the
issue of data download.
Oh sorry. On the client side of course - these which are under the
/var/cache/yum tree. My question was more targeted on the complains
about 1) metadata local size, 2) speed and 3) capabilities of the local
yum queries.
[Furthermore you currently reformulating "Package Management" as
"Software Lifecycle Management", so it would be normal for me to expect
that the data backend will have to be enhanced accordingly. Or will
libsolv stores be enough for all?]
Regarding the metadata download speedup, I completely agree with Florian
and others on the thread, that current bulk downloads should be replaced
with XML only downloads and incremental update of the local DB as a
first step and introducing *optional* metadata services (just XML git or
something smarter) for the mirrors which are willing to upgrade.
Thank you,
Alek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
