[Yum] thinking about the future again

[Farkas Levente]

seth vidal wrote:
>>   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.

but since yum must use with rpm it can be confusing if their naming are 
different.

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

this can be an acceptable definition but see later in versioning...

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

on thing is sure. there are some package which has more version installed
and there are a few package which is not the latest on a system.
therefore it should reconsider the definition of install and update!

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

I'm not against it. I'm just against the way as do it. in up2date there
is a configuration parameter which packages has to handle differently.
this my argument only.

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

ohh. ok. I'm just assume it's about hdr files.

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

no I'm not mixing distro, BUT eg postfix-2.0.7 rpms are good for BOTH 
rh8.0 and rh9 and it's in my other tree. so I'd like to add the other 
repository to both my rh8.0 and rh9 machines yum.conf. this is ok now.
but if you start to create some kind of cache files than you should have 
to think about it.


-- 
   Levente                               "Si vis pacem para bellum!"