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@xxxxxxxxxxxxxxx> AwesomePlay Productions, Inc.
