yum 2.1.0

[Sean Middleditch]

On Tue, 2004-08-31 at 14:36 -0400, Jeremy Katz wrote:
> On Tue, 2004-08-31 at 14:05 -0400, Sean Middleditch wrote:

> > Better also if you can get system-install-packages hooked up with those
> > two tools, so that when I grab a package from somewhere other than a
> > registered yum repository, dependencies can still be resolved and
> > installed.
> 
> Funny, system-install-packages will resolve with the system packages
> (using the same stuff as system-config-packages; realistically, they're
> the same code with slightly different code paths for UI and one or two
> other things).  The hope with hooking yum into things would be for this
> to be possible :)

Ah, yes, right.  I tried installing a package with a dependency on the
base CDs and it asked for it.  Without YUM integration it just can't
handle most of the packages found online, though.

> 
> > It'd also be nice if yum supported 'temporary' repositories that were
> > passed to it on the command line or through library calls, so, for
> > example, an application RPM could include some meta-data pointing toa
> > repository containing dependencies, so users don't have to a) manually
> > add the repository to their yum.conf or b) manually download all the
> > dependencies.
> 
> Hrmmm, that's an interesting thought.  Although with yum 2.1, you can
> just grab a snippet and drop it in /etc/yum.repos.d (instead of having
> to modify /etc/yum.conf) which makes it a little bit easier to begin
> with.

That's not bad.  That would also then allow the repository to be checked
for updated as well.

The integration could be through RPM meta-data, or one could make a new
XML format for describing a single package and any related repositories.
With a browser/bonobo plugin, one could go a good step towards Mike
Hearn's dream of package installation.  Have an icon on a web site where
clicking it would install an app and any dependencies, and the icon (by
being a plugin) would be able to change its appearance/state during and
after installation.

Simply having a tool that can grep a simple XML file with a list of
packages and possibly some additional repositories would be a simpler
first step.  Something like:

<?xml version="1.0">
<install>
  <package>myapp</package>
  <repository id="myrepo">http://mysite.com/yum/</repository>
</install>

The app would install all the package entries listed, and use the listed
repo(s) to find the package and any dependencies.  An application web
site would just have a link to that file and the app would be installed.
Take it to the next level with the browser plugin, and we'd have hella-
easy software installation.

Also, imagine a CD with some software.  The autorun script might open an
HTML page on the CD with a big "Install" button linking to an install
info file on the CD, which specifies the main package to install and
points a YUM repository also on the CD.  Again, hella-easy software
installation.  The entire fact that a packaging system is even being
used becomes something the user doesn't need to know (assuming the
installer UI is made nice and clean; then system-install-packages UI
right now is fairly clearly a geek tool).

Alternatively, another possibility would be to simply reuse the comps
database file format.  The install tool would open up a GUI showing only
the packages listed in the opened comps.xml file, which would then give
us the ability to have "components" (i.e. multiple packages with some
being optional) similar to what other systems have.

Imagine Mozilla including such a file on their web site.  User clicks,
the GUI opens up showing the Mozilla components (Browser, Mail, Chat,
etc.).  User selects the ones they want and then the RPMs are downloaded
and installed.

Obviously won't be a panacea until packages and developers start making
their software easily installable (i.e., library authors need to learn
about proper versioning, and package authors need to learn about making
packages that take advantage of libraries that are properly versioned),
but it would be a good ways better than what we have now.

> 
> Jeremy
> 
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.