[Yum] thinking about the future again

[Farkas Levente]

hi,
this are nice, but for me it's still not clear the goal of yum. but I
can tell you what kind of tool would be useful for me:
- a tool top of rpm which use as much from rpm as possibe (that's what
   I like in yum over apt).
- if rpm has some bug (like you said -F) than it should have to repair
   in rpm and not hack in the new tool.
- what I would like to use this tool: install, update, delete packages
   and some kind of other information(list, info). what does the above
   means is one of the key question here. AFAIS you always assume that
   only the latest package important for you (or otherwise you can use
   rpm itself). this can be one point of view but in this case it have
   to decide and clearly state at the begining. although I'm not sure
   that this is a good basic concept.
   - in this case what the difference between install and update?
   - what the "yum install x" means?
     - if the latest x was installed previously? do nothing.
     - if x was not installed previously? install the latest.
     - if x was installed previously but not the latest? it's not clear..
       in this case what's the difference from "yum update x"?
   - what the "yum update x" means?
     - if the latest x was installed previously? do nothing.
     - if x was installed previously but not the latest? update.
     - if x was not installed previously? it's not clear..
   the main problem here is this naming convention in not the same as
   what rpm use! so actualy I'm against it.

   if intall, update, freshen and delete(erase) has the same meanings as
   in the case of rpm than it's at least not confusing. but of course if
   we do exacly the same as rpm why we need yum? IMHO the real difference
   is the dependency resolving! so if we summarize the goal of yum as:
   "same as rpm but always automaticaly resolve all dependency too."
   than it's clear. IMHO when a tool try to solve to much problem then
   it's getting too big and too buggy.
   in this case:
   - what the "yum install x" means?
     install the latest version of x (and all of it's dependencies).
     if there was a previous version leave it as it was before. and
     all the dependencies also installed not updated!
     same as rpm -i x if x has no deps.
   - what the "yum update x" means?
     update to the latest version of x (and all of it's dependencies).
     same as rpm -U x if x has no deps. actualy it's not so easy. since
     if before this there was
     x-1.0 (depend on y-2.0),
     z-1.0 (depend on y-2.0)
     lastest is x-2.0 (depend on y-3.0), than yum have to install y-3.0
     and not update. but if
     x-1.0 (depend on >= y-2.0),
     z-1.0 (depend on >= y-2.0)
     lastest is x-2.0 (depend on >= y-3.0), than yum have to update to
     y-3.0.
   - what the "yum freshen x" means? same as rpm -F x if x has no deps.
     if x is already installed equal with "yum update x" otherwise do
     nothing.
- another thing is versioning. since almost all system has a few package
   which has more than one verion installed. yum also should have to
   support it. and here comes the above problems. like:
   yum install x-1.0
   yum update x-1.0
   yum erase x-1.0
- yum library is a good think.
- "yum update" is also a good think but I don't know what happend in
   case of x-1.0 and x-1.5 already installed and x-2.0 is the latest?
   so IMHO it's a dangerous command in most case.
- as I wrote earlier I'm really not like the idea that yum handle kernel
   differently! it's a hack! what's more a dirty hack! if you has a
   configuration option for exceptional packages it's ok. but to hard
   code some of them is not a good idea. on a mail server postfix can
   be as dangerous package as the kernel or ...
- read a command file would a good think, but IMHO it'd be after the
   next release.
- xml...hmm I like xml but AFAIS this usualy leads to a slow buggy
   program (just see redhat config tools). xml has the advantage in
   cross application data exchange. IMHO this is not the case with yum.
   hdr always be much faster. it can be a config options (to use xml or
   hdr) but never replace the binary header files.
- repository prioritization/scoring YES! eg in our mirror site there is
   a dir called "other" which contains about 3000 rpms downloaded by hand
   from different site and collected during the last few years. so not
   all rpms are up-to-date. and there is a mirror tree for redhat,
   freshrpms etc.. currently I can't use the other tree with yum. what
   I'd like to give priorities
   - redhat updates 100
   - redhat 90
   - freshrpms 80
   ...
   - other 10
   so only use a package from other if there is not the same package in
   a higher priority repository. and if there is two or more repository
   with the same priority and more has the same package than use the
   newer one.
- another useful thing would be if I can use this other tree both for
   rh8.0 and rh9. this came to the picure when you think about some kind
   of caching. in this case there is a different dep tree for rh9 and
   rh8.0 (so can't be put into the same directory:-)


-- 
    Levente                               "Si vis pacem para bellum!"