Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about?
Mo illustrated a few days ago about how confusing the updater is and I agree with her; and it’s mostly my fault for not pushing applications harder. Lists of unlocalized generic packages are so 1990’s, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs.
So, a solution. I’ve been working on app-install with some people from other distros for the last few months, and last week it had it’s first public release. Schema version 2 is already being worked on, and now optionally integrates with PackageKit and also provides some other features like sorting applications by rating and application screenshots. I’ve already generated distro metadata for the entire fedora repository (this takes about four hours on my laptop) and packages are available. It’s really easy to generate metadata for the other repos too, but I digress. Read the README file for all the guts about how it works.
I’ve got two demo applications that use the app-install data. One is an installer and one is an updater. These are work in progress, and show dramatically the lack of my UI design skills.
The installer will be an additional tool (much like the ubuntu-application-installer compliments synaptic) which is focused on ordinary desktop users. If you know what an epoch is, it’s probably not for you. The old tool will remain, so panic not. This tool will just install applications, that-is anything that ships a desktop file with an icon. Anything else just isn’t shown. Sorry! We will hopefully show groups too, perhaps even the same entries as the “Applications” menu.
The updater will be an improved version of the old package updater, and anything that’s not an application (e.g. PackageKit-libs-devel) will be under a group (not shown in the screenshot) called “System infrastructure“. If you update an application that depends on a package from the “System infrastructure” group then it gets pulled in as a dep. Otherwise you only update the system stuff (e.g. systemd, dbus, kernel) if you choose to select the “System infrastructure” metagroup. Of course, you can descend and pick updates in that group individually like before, if you know what you are doing, but I think most people will just install the metagroup as one lump.
Also, bear in mind that neither app-install or the application data packages are in distros just yet. This stuff isn’t well tested. The packages may steal all your magazines from your bathroom.
Now, I mentioned my ineptitude at designing GUIs. This is where you come in. I would love you add mockups of what you think an application installer or application updater should look like to this page. I’m going to ask Máirín (mizmo on IRC) to help with the design work, so please upload mockups I can share with her and the other design people. Thanks!
The 2nd mockup seems good enough to me at first glance, but I’ll give you some text feedback on the first one (because I’m le tired):
– Do not use progress bars for ratings, they look bloated and they don’t indicate progress. Maybe a rank of 5 stars (with half stars precision)? Just rip rhythmbox’s code for that I guess :)
– Shouldn’t the “Find” button should be on the right? Actually, why do we have a find button? If performance allows, let’s replace it by a “Search: ” text label, and have the thing autosearch when you type more than 3 characters in the search entry and when you pause for more than 1 second.
– The “Installed” column… I’m not sure its meaning is clear (ie: is it a status indicator or an action?). Maybe “Add/remove” would be clearer.
– There should be [ Quit ] [ Apply changes ] buttons on the bottom right.
– The ubuntu software centre “categories” seem to make sense to me.
The progress bars will of course be replaced by stars in any final version. The demo application now does search-as-you type. so maybe we can nuke the find button altogether.
Why all this duplication of work when there is already excellent alternatives such as the above mentioned Software Center? Why not work on it with Ubuntu devs so you can plug PK into it and get all the fancy UI for free?
There is also a spec for the Software Updater here: https://wiki.ubuntu.com/SoftwareUpdates?action=show&redirect=SoftwareUpdateHandling
The Ubuntu Software Center is hardcoded in many places to use ubuntu-specific functionality. It would be a re-write to make USC generic.
I had a quick look, and it seems there is some work done to work on more than Ubuntu, there is a distro/ directory with both Ubuntu.py and Debian.py, and the installation logic seems nicely isolated in backend/aptd.py.
Of course this is not all, and there is for example some hardcoded ubuntu.com URLs, to get screenshots for example; but I don’t think it would amount to a complete rewrite to get it to work with PackageKit and other distributions, and doing it anew means we’ll miss the important usability work that went into the ubuntu software center (at least it appears so, but I don’t follow ubuntu development closely).
Considering what Frederic Peters said it looks like you can (easily) add support for Fedora into it and fix the hard-coded parts for the benefit of all. Take into consideration that USC and the software updater specs were created by a usability expert.
1) Does USC require copyright assignment to Canonical?
2) Is there a documented API for creating other packaging backends besides apt and the deb package format in USC? If you look closely at the code a lot of the functionality is tied directly into the specifics of deb fileformats..and not abstracted out via an API for other packaging backends to use. It may be enough to change a few urls for Debian or Mint but it wouldn’t work for Gentoo or Meego without significant re-engineering to abstract the package manegement support.
Its probably more correct to say that USC very deb-specific and would need to be significantly reworked to be work with non-deb distributions. How much work would it be for users of portage based systems like gentoo to use USC? I think a lot. Whereas packagekit already has an abstracted framework and app-install builds on top of that.
I would suggest you at least read the readme for apt-install and then reach out to the named collaborators there for their opinions as to technical merit of the effort.
-jef
0) I had a very quick look at software-center, I certainly don’t know much about it, @zekopeko, plase don’t take my quick look as a definite analysis.
1) at least it doesn’t require copyright assignment to be forked to git.gnome.org and developed there…
2) there is backend/aptd.py, which is not that long, with correctly named and briefly documented methods (install, remove…) and it looks like they do defer to aptdaemon, which is just like PackageKit (the D-Bus API may even be very close, but I didn’t look). I still think it wouldn’t mandate a total rewrite.
3) Most importantly I have no plan to work on this, therefore I understand my impression have little value.
Frédéric,
I don’t understand your insistence on trying to make the argument that it will be easier to adapt software-center to non debian packaging. In 0) you say you don’t know much about it. But in 2) you make the argument again that its technically easier to port it than to re-engineer it. I implore you to actually take a very close look at the code and look at how extensively functions from python-apt are used throughout the codebase… none of which is abstracted as far as I can tell. That aptd file doesn’t come close to fully encapsulating the apt-specific functionality. Pull the code, and grep for “apt” and start tracking the use of functions pulled from the python modules apt, aptsources, apt_pkg. All the information gathering bits would have to be re-engineered to be abstracted.
USC was not built with abstraction to other packaging formats in mind. It’s a purpose built piece of software meant to integrate with Ubuntu and Launchpad and was not built with any expectation beyond that. And that’s fine, but let’s not kid ourselves about the utility of the codebase as a piece of widely reusable code.
-jef
(Funny how comment threading seems to stop at a certain level, even removing the “Reply” link, actually perhaps a good idea to avoid long discussions in comments).
My insistance (well, it’s just two comments, now three) probably comes because we have no lack of good developers, but we have a limited number of designers, and we could benefit from the important design work that went into the ubuntu software center. (fwiw “we” = “the GNOME community”).
I had a closer look at the source code, and still I believe we would achieve something better faster by adapting it to PackageKit, than by recreating something new.
(below some comments on the code, as I read through it and took some notes)
FWIW, many references to apt are into “if __name__ == ‘__main__'” parts, in files that are not supposed to be executed, for testing purpose.
Then there is apt_pkg.size_to_str() which should be replaced by the glib counterpart. apt_pkg is also used to find some configuration parameters (architecture, path to log file), this is minor.
And mostly it uses aptdaemon, which has a D-Bus API similar to PackageKit, and a Xapian index of packages, which it not native to apt.
Wow, that’s good news. Nice that someone picked up the ideas and pushed them!
The cool thing of the Linux Desktop is that you can update everything from a central place and a cleaner UI will make that much more transparent for the end-user!
Thanks!
That’s nice that this is getting to Fedora and other RPMs distros. One thing (not related) I keep asking myself is Why we can’t auto-update the systems with only security-fixes. I think most users will just choose to stay in a stable repo + security fixes and these should be installed automatically (if the user has chosen it when installing the system) without user intervention. Since now Ksplice is getting to Fedora, this probably could be made in a way that you don’t even need to reboot your system. Another thing I would like to see is to have some kind of “time machine” for the status of your system, where this means that each time you update some packages, there is a record with enough information so the user could choose to revert one or some of the package’s updates.
A quick note from me on the ubuntu software-center packagekit backend. It should not be hard to do that, as was pointed out by Frédéric Péters. The demands on the packaging layer are pretty small, most information comes from the app-install layer. The backend should be easy to switch to PK.
Fedora updates often comprise of related packages pushed out together (e.g. update FEDORA-2010-5392). Additionally a package (and its subpackages) may contain multiple applications.
So an application-wise view of updates may be not be much more user-friendly than a package-wise view of updates. For example, an ordinary desktop user may be presented by a long list of applications to update, which belong to a much smaller list of packages. Or they may be presented with a list of applications which can only be updated together (e.g. firefox and chatzilla, or any other xulrunner-based app).Or they may be presented with a KDE SC 4.x.y update, which comprises of a bewilderingly long list of items (whether viewed as applications or packages) but only makes sense to update all together.
If you’re going to redesign the update UI for “ordinary desktop users”, shouldn’t it also better reflect the way updates are structured? That is, one entry for all firefox + xulrunner updates (or packagekit updates, or kde/openoffice/kernel/etc. updates) with the options to view a detailed list of packages (or applications?).
See also my comment at http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/#comment-7207
app-install will be nice for an Ubuntu Software Center alternative, but for the update manager, I propose to use
no interface at all
and update automatically in the background.