Notes on Yum Changes

seth vidal skvidal at phy.duke.edu
Tue Sep 7 21:30:44 UTC 2004


> Yum itself has to handle the installation anyhow to make sure it
> actually works.  Imagine a case where you are installing a local package
> foo, which provides a virtual bar, and depends on baz, which requires a
> package providing bar?  Yum has to know about the package being manually
> installed to be able to satisfy the dependencies properly.  An
> external/separate tool would pretty much be forced to take the local
> package, calculate its dependencies, request them from Yum, and once
> those are already installed, install the package requested by the user -
> the sort of chain above could not ever be properly resolved in this
> case.
> 
> Again, there isn't anything wrong with yum installing local packages.
> It's the natural tool to do the job, and there isn't any compelling
> reason to do otherwise.  "Feels wrong" does not count as a compelling
> reason, either.  ;-)

So here's a compelling reason:

I've done a lot of work to make it so a user could 'import yum' and work
from there with all the packageSacks from repositories and have access
to the rpmdb.

But right now I'm fairly positive b/t the above requested features and
the AI that other people want yum to become to magically solve all
problems and tap you on the shoulder about it that I'm not going to have
time to do it.

I work on yum in my spare time, it's not part of what I'm paid to do in
my day job. So if there are considerable features people want to see
developed then they're going to need to put up some functional,
non-hacky code for it.

The api for yum is, right now, not stable and I'm not sure when it will
hit stability but I'm more than willing to talk about what people need
and try to make the yum module work even better as a simple module for
utility authoring.

so right now that's the limitation.
-sv






More information about the fedora-devel-list mailing list