[Yum] First experiences with Yum

[seth vidal]

On Sun, 2003-07-27 at 09:53, Jos Vos wrote:
> Hi,
> 
> After reading about Yum on the RHL beta mailing list and experimenting
> with apt-rpm, I decided to try Yum.  Here are my questions and
> comments (I'm using RHL 9 as both the server- and client-platform,
> using the yum-2.0-1 rpm found on the Yum web pages):
> 
> -  The man page of yum suggests that the -z flag will compress the
>    header info, but it seems that this always happens and that the
>    -z flag effectively is a no-op.
> 

very true - it used to have meaning and I left it in place so people's
scripts wouldn't bail out with a 'no option named -z' error.

> -  I want to force a priority sequence for my Yum servers, so that
>    packages of a higher prio server do *always* take precedence over
>    packages of a lower prio server, regardless the version numbers.

>    I assumed "pkgpolicy=last" would do this, but it seems to work only
>    partly: when a new package is installed, it indeed takes the one
>    from the higher prio server, regardless how the version compare.
>    But if a package is already installed, it doesn't upgrade (in my
>    case this means downgrade) to the version of the higher prio server.
> 
>    I can't really understand this policy, as in this way client
>    systems using the same Yum servers end up with different package
>    sets (versions), dependent on the time a package was installed.
>    This is an unwanted behaviour, IMHO, as systems like Yum should
>    ensure a uniform set of client systems (except for what packages
>    are installed, but this can be tweaked with special packages).


downgrading is not as easy as it appears and dealing with downgrades in
operation will take some effort.



> -  Running "yum install ..." sometimes results in a segmentation fault,
>    but doing it again works fine then.  Sometimes it also hangs, but
>    this is a known problem with rpm (rm -f /var/lib/__db* ...).

You should look HARD at the system in question about the segfaults. I
haven't gotten ANY segfaults from yum that weren't related to hardware
going funky.




> -  Kernel "upgrades": Yum installs the kernel (i.s.o. upgrading it),
>    which is fine, but this seems to be a built-in feature.  Can I also
>    do this with other packages (like the "allow-duplicated" in apt-rpm)?

no - you cannot do this at this time. It is planned to have a list of
pkgs which are marked as 'install-only'.

allow-duplicated is bizarre in my opinion - allowing dupes is obvious -
but knowing when to install something instead of upgrade is
not-so-obvious and therefore useful.


> -  Making the new kernel the default should be an option, I think.
>    See also the remark about scripting below, as I would like to see
>    this done in an external script or Python module, instead of
>    having this as built-in code.

look at the todo list - it's on there - it's not a trivial abstraction
to do in one cut.

The trick is planning the features enough in advance to know what you're
going to get. B/c once you setup the external scripting and what it
passes on to the external scripts you're stuck with that api for a
WHILE.

So it's been on the 'thinking about' burner for a bit so I don't end up
painting myself into a corner with some ridiculous interface to it.



> -  When I rename a server id in /etc/yum.conf, the old cache info
>    (with the old server id) never seems to be removed, not even
>    with "yum clean all".

right -b/c at that point yum knows nothing about it. It's the only nice
way to deal with multiple config files - so they don't tread on each
other's cache.


> -  RFE: I would like to be able to run scripts before or after rpm
>    actions being done (like the LUA scripts can do in apt-rpm).
>    I know this is Python and it should be probably pretty easy to
>    add myself, but maybe this can be made a generic feature?
> 
> In general, I like that the code being *much* smaller than apt-rpm
> (why is this so extremely huge...) and more accessible (as it is
> Python), but I think a few more features would make it better suited
> for enterprise-level use.

Well if I had my druthers (and fortunately I do, to some extent :)

I'd like to have a set of external python scripts that handle kernel
updates and kernel modules and all sorts of stuff like that - these
scripts would come in the yum rpm by default but you could easily add
more in a sane way.

As it is - I want yum's default behavior to stay relatively the same. I
like that it handles kernels correctly out of the box, I like that I
don't have to tell people to specify some bizarre incantation to get
kernels to install, let alone update grub.conf correctly.

so make your list - and put them in some RFE's in bugzilla and I'll get
through them as I can or as it makes sense.

if someone wants to make patches against cvs for such things let me know
- I'll be interested to see what can happen in the coming months to free
up a lot of the older crufty code that eats up space in yum.

-sv