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
On Thu, 2007-05-17 at 14:23 -0400, Colin Walters wrote: [snip]
No support for conflicts[1], removing packages[2], installing multiple packages at a time[3] (if the user clicks multiple, just queue them up),
This is a fundamentally broken assumption. Multiple packages are required because packages can and do depend on other packages. Even things like python-paramiko, etc.
All that said -- it'd be trivial to split out the search bit of pirut and have that run stand-alone. But that doesn't get rid of the need to do transactions, depsolving, etc.
Jeremy
On Thu, 2007-05-17 at 14:34 -0400, Jeremy Katz wrote:
This is a fundamentally broken assumption. Multiple packages are required because packages can and do depend on other packages. Even things like python-paramiko, etc.
Sure, I guess I didn't mean transaction in the techncial sense but more like how it's exposed in the interface; i.e. that you don't need to take the current approach that pirut does where you click on a bunch of things and then have an "apply" step and a confirm step, or yum's install confirmation. Could just start downloading and installing on the first click.
On Thu, 2007-05-17 at 14:37 -0400, Colin Walters wrote:
On Thu, 2007-05-17 at 14:34 -0400, Jeremy Katz wrote:
This is a fundamentally broken assumption. Multiple packages are required because packages can and do depend on other packages. Even things like python-paramiko, etc.
Sure, I guess I didn't mean transaction in the techncial sense but more like how it's exposed in the interface; i.e. that you don't need to take the current approach that pirut does where you click on a bunch of things and then have an "apply" step and a confirm step, or yum's install confirmation. Could just start downloading and installing on the first click.
And then people complain you didn't tell them what was going to be pulled in or why did this that or the other get installed or why did something get _removed_ due to an obsoletes.
And the people who complain the most about this stuff are the exact people you're trying to target with this interface (developers and sysadmins).
Jeremy
On Thu, 2007-05-17 at 14:43 -0400, Jeremy Katz wrote:
On Thu, 2007-05-17 at 14:37 -0400, Colin Walters wrote:
On Thu, 2007-05-17 at 14:34 -0400, Jeremy Katz wrote:
This is a fundamentally broken assumption. Multiple packages are required because packages can and do depend on other packages. Even things like python-paramiko, etc.
Sure, I guess I didn't mean transaction in the techncial sense but more like how it's exposed in the interface; i.e. that you don't need to take the current approach that pirut does where you click on a bunch of things and then have an "apply" step and a confirm step, or yum's install confirmation. Could just start downloading and installing on the first click.
And then people complain you didn't tell them what was going to be pulled in or why did this that or the other get installed or why did something get _removed_ due to an obsoletes.
Seems solvable - display below each name the list of packages you'd need to install to get it. I doubt any of these have huge dependency trees because we're assuming for this tool that you already have base things like the 'Development Tools' group installed. I'd imagine this tool would come with that group, or maybe we need a 'Base Development Environment' that has graphical things. Would be cool to have anyways say for a spin of Fedora explicitly targeted for developers.
As for packages getting removed...are there really any developer tools that obsolete earlier ones that would matter to someone? The obsolete type situations I imagine would mostly have already been done when someone does a big upgrade from Fedora x to x+1, not after they've installed.
Anyways...techncial details! Think about how cool it would be =)
Le jeudi 17 mai 2007 à 14:43 -0400, Jeremy Katz a écrit :
On Thu, 2007-05-17 at 14:37 -0400, Colin Walters wrote:
On Thu, 2007-05-17 at 14:34 -0400, Jeremy Katz wrote:
This is a fundamentally broken assumption. Multiple packages are required because packages can and do depend on other packages. Even things like python-paramiko, etc.
Sure, I guess I didn't mean transaction in the techncial sense but more like how it's exposed in the interface; i.e. that you don't need to take the current approach that pirut does where you click on a bunch of things and then have an "apply" step and a confirm step, or yum's install confirmation. Could just start downloading and installing on the first click.
And then people complain you didn't tell them what was going to be pulled in or why did this that or the other get installed or why did something get _removed_ due to an obsoletes.
And the people who complain the most about this stuff are the exact people you're trying to target with this interface (developers and sysadmins).
+10 no more of this "it's hard/not-windowsish so let's not do/expose it" madness. We don't need an "easy" broken-by-design model and we don't have to be ashamed of how our tools work (compared to the competition)
Users won't complain long if the stuff works. Making sure our model works is where efforts should focus.
On Thu, 2007-05-17 at 21:03 +0200, Nicolas Mailhot wrote:
+10 no more of this "it's hard/not-windowsish so let's not do/expose it" madness. We don't need an "easy" broken-by-design model and we don't have to be ashamed of how our tools work (compared to the competition)
Not sure what you're saying here...clearly what Fedora has now is way better than Windows since there is basically nothing equivalent there; I was hoping to think about how we could do even better.
Also there's nothing about shame here...the fact that yum exists doesn't mean that the rpm developers should be ashamed. Likewise, taking the "http://serversoftware.fedoraproject.org" example, that doesn't mean anything is wrong with yum! Clearly it would backend to yum.
I'm just trying to think about the kinds of things we can build on top of those tools, especially when you consider targeting design for particular audiences or particular classes of package. And also when you consider things like more tightly integrating Fedora-the-software with Fedora-the-website.
Anyways I think my first example got too sidetracked by the specific details of transactions or whatever...skvidal is doing some work on search which should help in getting through Fedora's huge collection of developer stuff. Personally think the "http://serversoftware.fedoraproject.org" idea is a lot more interesting thing to talk about and was hoping to spur discussion on that =)
On Thu, 2007-05-17 at 15:45 -0400, Colin Walters wrote:
On Thu, 2007-05-17 at 21:03 +0200, Nicolas Mailhot wrote:
I'm just trying to think about the kinds of things we can build on top of those tools, especially when you consider targeting design for particular audiences or particular classes of package. And also when you consider things like more tightly integrating Fedora-the-software with Fedora-the-website.
Anyways I think my first example got too sidetracked by the specific details of transactions or whatever...skvidal is doing some work on search which should help in getting through Fedora's huge collection of developer stuff.
let's try this on yum 3.1.5 or higher grab:
http://linux.duke.edu/~skvidal/useful-scripts/search-sorting.py
and run:
python search-sorting.py term1 term2 term3 term4
it should return the top ten hits matching those terms in order from most to least matches in a single package.
that's a start, at least.
-sv
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.
Well, why not start integrating pre-configured "puppet recipes" that configure the server software (postfix for example) for popular configurations. The way I see it, you select your server software, and you get a list of popular configurations: 1) Standalone primary mail server 2) Backup MX mail-server 3) Anti-Virus, Anti-Spam gateway
The user chooses a configuration, gets a simple web-interface to fill "parameters" as in "your domain name", "the primary MX IP address" ... etc
The user clicks "Go", the software is downloaded, installed, configured, started. New users will be happy, advanced admins will hack on the configuration even more.
On Thu, 2007-05-17 at 23:39 +0300, Ahmed Kamal wrote:
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.
Well, why not start integrating pre-configured "puppet recipes" that configure the server software (postfix for example) for popular configurations.
Ah, interesting idea, yeah. A long time ago when I was a Debian developer and into server software, I wrote the "debconf" bits to configure postfix with a few common scenarios, although less complex ones than you're suggesting.
I think it wasn't hugely successful (and the same is true of debconf in general) because a good number of admins want more flexibility, and control/understanding of what's going on. Now certainly it's not exactly the same thing as what you're talking about, but it just reminded me. Could be that puppet is a better technology for this sort of stuff than debconf is though.
I guess what I would maybe think about is more generally allowing people to attach files like sample configurations or their puppet scripts to the package wiki pages. Wouldn't it be cool if Fedora made it really easy to edit the "http://servers.fedoraproject.org/wiki/postfix" wiki page and add "Joe Bob's Tutorial on setting up Postfix+ClamAV", and then if he made it all into a puppet script he could add it there. Right now you often see pages like this that are kind of random - wherever the sysadmin happened to find web hosting.
Actually just for the very first cut I think having a defined wiki page for server software where people could add just random content like: "Here's what I did to make my config work with SELinux on FC6..." "If you're setting up Postfix, be sure to check out [[ClamAV]] too." in addition to a link to the upstream website's common installation instructions or other tutorials around the web would be a pretty nice first step. Things like comment/discussion boards, reviews, configuration file attachements could come later.
Le jeudi 17 mai 2007 à 23:39 +0300, Ahmed Kamal a écrit :
Well, why not start integrating pre-configured "puppet recipes"
You can already dump recipes and config samples in %doc Anything that tries to go further by adding an UI to blindly fill fields in those recipes is overengeneering. We have countless examples where this was tried and only resulted in very broken systems no one trusted. gconf is hated because of this and they started from a semi-sane structured file syntax designed to allow UI writing
Just write good sample config files. Ping upstream so it sanitizes its config syntax. That's more work and less sexy than slapping an UI and worrying fonts and icons but it's the only successful approach.
Colin Walters <walters <at> redhat.com> writes:
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: [ 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.
This is essentially how Synaptic works already. Searching ssh python on an FC6 system gives you: cobbler, denyhosts, pexpect, python-paramiko, python-twisted-conch, rdiff-backup.
/----- | 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.
Those 2 are essentially the same thing. Unfortunately, Synaptic won't help you here, but this works: repoquery -f /usr/bin/hg as does this: repoquery --whatprovides /usr/bin/hg However, both these only work by full path name, searching for just db.h won't work.
But I think all this could easily be done with the already-available RPM and repomd infrastructure, which already contains full file lists for all packages in the repositories. No new packaging system needed, no additions to the repository even, just some work on the client side. (In fact, you could even write a shell script which does a repoquery -a, then repoquery -l on all the results, and greps for the file name in this. But it's a lot faster faster if you read the metadata in only once, of course.)
Kevin Kofler