14.04.2012 20:44, Reindl Harald wrote:
Am 14.04.2012 18:39, schrieb Richard W.M. Jones:
On Sat, Apr 14, 2012 at 06:21:15PM +0200, drago01 wrote:
On Wed, Apr 11, 2012 at 8:01 PM, Richard W.M. Jones<rjones@xxxxxxxxxx> wrote:
I'm not arguing that's how yum works now, but it doesn't have to work
that way!
It could incrementally download the RPMs during depsolving, test that
they work together, and with that information download further
packages as necessary ...
Ugh no ... the whole point of the repodata is to avoid having to
download the rpms to calculate deps.
Well the "whole" point is to get the best possible software quality,
user experience and performance (accepting that we cannot maximize all
of these at the same time). It's my personal opinion that yum does
not do well on any of these three criteria.
and you think performance and user experience will get better
by downloading packages for dep-solve?
are you aware that many people do not have endless bandwith,
traffic-limuts and storage and can you imagine how slow
this all would be?
yum should not waste ressources which i did even in the
recent past by consuming wy too much memory resulting
get killed from oom-killer on machines with 512 MB RAM
and yes, 512 MB RAM are really enough for many servers
and there is no argumentation for a UPDATER eating more
ressources as the whole server in normal operations
What the point always store it in XML or Sqlite static files instead of
provide service on server side to speedup solving?
Off course it may require some script running on server side to provide
such service and some limit mirroring (there may be fallback to old
scheme), but also it may have many benefits:
1) On server side metadata may be any size, optimized for inner use if
it will not intended to transfer each time.
2) It may be cached.
3) Clients may ask only small parts of data, which is most cases is what
wanted.
As I look it for me for first glance.
Install or update one package scenario (yum install foo):
1) Client ask last foo package version.
2) Server calculate all dependencies by self algorithms and return in
requested form (several may be used from JSON to XML) full list of
dependencies for that package. No other overhead provided like
dependencies of all packages, filelist etc.
3) Client got it, intercept with current installed packages list,
exclude whats already satisfy needs, and then request each other what
does not present starting from 1.
Update scenario (yum update):
1) Client ask repo-server to get a list of actual versions available
packages.
2) Server answer it.
3) Client found which updated and request its as in first scenario for
update.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
