Software Management call for RFEs

Jan Zeleny jzeleny at redhat.com
Tue May 28 18:38:15 UTC 2013


Dne Út 28. května 2013 14:59:20, Alek Paunov napsal(a):
> 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.

I'm not sure merging database would help in any of these areas. But then again 
I can be wrong. If you plan to do the testing, I am very curious about the 
results.

> [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?]

This has to be discussed along the way, at this point it is too early to say 
what will happen to metadata.

> 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.

We are performing some tests and so far it seems that for yum this is not the 
way to go, as the speed gain would be compensated by the local yum db rebuild. 
We will continue to work on this but so far it seems that dnf is the way to go 
so the optimization will most likely happen there.

Thanks
Jan


More information about the devel mailing list