Recently as part of the online desktop project we've been doing some work on installing desktop applications, a blog entry is here: http://clarkbw.net/blog/2007/05/04/bullish-on-finding-new-applications/ However, what I was thinking about on the drive in this morning though is how we could make the experience kick ass for the other kinds of software out there, like developer libraries and tools (foo-devel, mercurial) and server software (postfix). For the first part - developer software, my ideal tool would look something like this. Just a search box, and a list of result hits. Like a web search engine basically. /----- | Search: [ hg ] | | Package: mercurial _Install_ | - /usr/bin/hg | \----- Searches executable names /----- | Search: [ db.h ] | | Package: libdb2-devel _Install_ | - /usr/include/db2/db.h | | Package: libdb3-devel _Install_ | - /usr/include/db3/db.h \----- Searches files. /----- | Search: [ ssh python ] | | Package: python-paramiko _Install_ | "Paramiko is an implementation of ssh for Python..." | | Package: openssh _Install_ | - /usr/bin/ssh \----- Searches descriptions and names too. No support for conflicts[1], removing packages[2], installing multiple packages at a time[3] (if the user clicks multiple, just queue them up), updating to new package versions[4], whatever. Let me search for that developer thing I need and one click blat it to the disk from the web. Menu entry would be 'Install Programming Tools'. Would require a local cache of the contents of all packages - also being able to search the individual symbols in things like shared libraries, Python modules, etc. Probably large, but I bet gzip would do quite well on it for a CD, and hard disks are big so store uncompressed to make it fast. Use rsync to periodically keep it up to date. Or perhaps we could dump the local cache idea and have it be a fedoraproject.org web service. Now there's another class of software - server software like apache, mediawiki, postfix, etc. These kinds of packages could legitimately conflict with others. But the difference is a lot more fundamental - for this kind of software, downloading the package is only the *very first* step in actually getting it working. You have to configure these, and there's no way around that. We could talk a lot about what installing server software could be like, but an idea of where we could go would be towards something like "RHX for Fedora": https://rhx.redhat.com Being able to click on Postfix and click on reviews, comparisons to other things like Sendmail would be cool. I know we have some people that are passionate about particluar server software that would likely add reviews. Could be hosted on the fedoraproject.org wiki. A super small thing that would be *easy* to implement for server software would be to include a "Next-Step-URL" or something in the RPM spec file that opens in a browser after you install the software. Let's be realistic - admins rely on the web for setting these things up. Unless you're an admin god, but in the case you are you can help add to the wiki page =) We could define this to always point to a fedoraproject.org wiki page, which could then link to "official" setup instructions like: http://www.mediawiki.org/wiki/Installation and also have Fedora-specific tweaks and instructions, like a link to a description of the Fedora Apache SELinux policy, etc. If there was no content on the fedora page it could just be an auto-redirect to the upstream site until some content is added. Anyways, just some random thoughts. [1] None of this software should conflict with anything else. [2] Should be extremely rare to remove any of this stuff...in the odd event you are really scraping for disk space, an "out of disk space" tool could detect which things are unused, but it's more likely anyways that what's actually eating your disk space is all those Battlestar Galactica or whatever episodes you've been bittorrenting. Bad user! [3] Don't need transactions, etc...as soon as the user clicks start downloading and installing. Since there are no conflicts there shouldn't be an issue. [4] The pirut update applet is great for this -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
