random thoughts on software installation

Colin Walters walters at redhat.com
Thu May 17 18:23:12 UTC 2007

Recently as part of the online desktop project we've been doing some
work on installing desktop applications, a blog entry is here:

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":

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:
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

More information about the fedora-devel-list mailing list