I'm going to respond throughout.
On Thu, 2003-04-17 at 08:43, Farkas Levente wrote:
> hi,
> this are nice, but for me it's still not clear the goal of yum.
Yum is a package management tool. It is intended to make dependency
resolution for pkgs simple and relatively automated. It also was
intended to handle automatic updates of diverse systems in a consistent
manner.
> - 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..
no if x was not installed previously update will NOT install
it.
> the main problem here is this naming convention in not the same as
> what rpm use! so actualy I'm against it.
I don't agree with certain choices in the functionality that rpm uses
and I'm fairly well supported in that regard by an array of others. I do
not like the idea of update installing things - otherwise you end up
with no the word "update" lacking meaning for use.
can I update something I DON'T HAVE? No, I can't it's doesn't make sense
w/the word.
My general take is that freshen is a syntactical booboo on the behalf of
rpm - it is correct in terms of what it does to pkgs but the term is
ambiguous wrt to update.
and I know I have repeatedly answered the question "no, update will
install anything, no you'd want to use something like freshen"
So let me give the definitive versions:
yum install - installs pkgs - if it finds there is a newer version of
pkg x and you have pkg x installed it will mark it as updateable. Maybe
it shouldn't but it was a convenience feature
yum update - it will update pkgs that you have installed - nothing more
yum erase - this should be pretty obvious.
> - 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
I did some thinking about this - it will require some restructuring of
the nevral class and some other additional work to handle it smoothly. I
think the default case would still be to operate only on the most recent
versions.
> - 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 ...
No it's not. the kernel installation/update mechanism used in yum is the
exact same as is used in anaconda, in up2date as was used in yup and is
as recommended by red hat in their kernel errata notes. The kernel
install/update "hack" as you call it won't be going away. IT will be
expanded and made more general to fit in with specific pkgs you want to
customize as "install only" but it will definitely stay.
> - 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.
We're not replacing the hdr files - the whole point of the hdr files was
to use the normal rpm mechanisms to read the headers and do version
calculation.
the header.info file is a flat ascii file that stores some fairly bland
things. The point would be for yum-arch to generate a compressed xml
header.info instead of the flat ascii header.info it generates now.
why? it would be smaller, it would make parsing easier in the long run
and it would make flexibility greater if meta data can be defined
liberally enough.
> - 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.
right - that's what that would be about - but it will take some time for
me to get to it.
> - 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:-)
don't go mixing distro versions - that is fast track to insanity and
hell.
-sv
