All entries for December 2006
December 10, 2006
Today I updated my package search page to include openSUSE 10.2 repositories. I also modified the repository trawler to use the openSUSE buildservice api to locate repositories, and had it index all the valid 10.1 and 10.2 repositories in the build service.
This was quite straightforward as https://api.opensuse.org/source simply returns a list of repository names which can be easily converted to the appropriate URLs on http://software.opensuse.org/download/ .
There are now 221 valid 10.1 repositories indexed, and already 88 valid 10.2 repositories. Approximately 13,000 packages per architecture for 10.1. Only about 8100 packages per architecture built so far for 10.2 , but it was only released on Thursday. That translates to about 5 million files for 10.1, 3 million for 10.2.
openSUSE 10.2 release
As I mentioned above openSUSE 10.2 was released on Thursday, and it is looking like it could be one of the best SUSE releases to date. Few issues remain in the final release, and there are lots of user-visible improvements over previous versions. Some of these are shown in the screenshots page: http://en.opensuse.org/Screenshots/Screenshots_openSUSE_10.2 It is certainly a relief that pain of supporting users with 10.1 will soon be mostly over.
A tip to those installing 10.2, deselect the “Enterprise Software Management” pattern and select the “openSUSE Software Management” software pattern (pictured at http://en.opensuse.org/Image:Screeny102_software_patterns.jpg) during or after install. (The former pattern contains software that was partly responsible for many of the problems in 10.1, and still has issues: http://www.desktoplinux.com/articles/AT5310810296.html). I disagreed with the decision to leave it in the default install, and it looks like my fears were justified here.
With the release of 10.2 out of the way, now is an ideal time to start setting some goals and starting some projects for openSUSE 10.3 and beyond. To this end we have organised a community meeting to help increase community involvement in improving the distribution. This will be held in 1 week (Saturday 16th 18:00 GMT) in #opensuse-community on the freenode irc network, see announcement and explanation here: http://lists.opensuse.org/opensuse-announce/2006-12/msg00003.html
This is the first time anything like this has been attempted, so it would be great if as many people as possible could turn up. It gives you the opportunity to find out what is already going on, help brainstorm improvements to openSUSE, and perhaps even get involved yourself.
December 04, 2006
It seems to me there are several generations of package management:
- 0th Generation – No package management, user must place individual files in the correct place on his/her system.
- 1st Generation – Software is packaged for easy installation on the target system, user can just extract/run the package and files are placed in the correct place, but there is no dependency checking. If something the programme requires to run is not available it will simply fail to work when run. Examples: old style windows installers, zip files, slackware packages.
- 2nd Generation – Builds on 1st Generation by adding dependency/prerequisite support, so user can know what prerequisites he/she must install in order to use the programme. Examples: MSI, dpkg, rpm.
- 3rd Generation – Builds on 2nd generation by adding automatic dependency resolution from software catalogues/sources/repositories. This means that if all the software & dependencies that the user might wish to install are available in the pre-configured repositories he/she can easily install anything. Examples: apt/smart/urpmi/yast sw management .
We seem to have remained at the same basic concept of 3rd generation package management for quite a while. However, there are a remaining issues that stop it from being as useful as it could be. Problems I see with 3rd generation package management:
- User has to learn how to use a package management frontend. Be it apt-get, synaptic, yast, smart, or whatever. The design of these interfaces vary in ease of use, but even the best designed may still seem foreign to windows users conditioned into double clicking an install file and clicking next repeatedly until done.
- The packages may not be in the standard preconfigured repositories. This can happen both for legal and practical reasons. Some software is not legal to distribute freely everywhere in the world, and no repository can contain all software in any case. In the situation where the software the user wishes to install is not available in the already configured repositories, he or she will have to locate the repository where the software is located, and then learn how to add it as a source to whichever package manager he/she is using. All of which is a lot of effort for someone who just wanted to install something.
So, how can we solve these issues?
Well one solution is to make use of some form of meta-package file which simply contains information about software, and the repositories where it can be located. On top of a 3rd generation package management system this could enable:
- Single click adding of software catalogues, without the user having to worry about where they are located, or how to add them.
- Single click installation of software, whether the repository the software is located in is currently configured in the user’s package manager.
Today I had some spare time so I knocked up a proof of concept for how this could work:
With a YaST module to interpret the above, and a default association for the file type in my file manager/web browser I have a working proof of concept for easy package installation.
So the user sees a link to “install tuxsaver” on a website or otherwise obtains the above installation file. And decides he/she wishes to install it. User clicks the link, and the appropriate repository can be added and the appropriate packages installed.
Alternatively if no packages are specified for installation, the same file handler could act as an easy way to add additional package repositories to the package manager.
If the module were opened without a file as a parameter it could grab a regularly updated list of available software catalogues from a central location. Obviously repositories hosting packages with dubious legality could not be listed here. However it would enable a project such as packman which is in this situation to host a “Click here to add our project catalogue” link on their homepage, and a “Click here to add mp3 support to your SUSE Linux” etc.
I think a proper implementation of this concept, included in the distro install by default would have potential to greatly simplify the package management experience for users.
A few issues were raised while I was looking at this which will need addressing:
- de-duping repositories.
There is no sense in a user having the same package repository added to their package management system twice. My demo will only re-add a repository if the same URL hasn’t already been added, but the same repository may have different URLs on different mirrors. There seems to be no unique repository identifier in rpm-md repositories. One possibility is using the md5sum of one of the metadata files, but this would require making several checks, and ensuring the repository metadata is synced before the process can start.
- Security issues.
This demo gets for free the security warning from YaST when adding an untrusted repository. It is likely a more clear warning will be required of both the security and technological issues that can be caused by installing random software.
Clearly the format of the meta-package file would need to be thought about carefully. What information does it need to contain, can it be bundled with packages to allow third parties to distribute RPMs which depend on packages in other people’s repositories.
Hopefully this demo might explain the concept better than my previous attempts, and might inspire some real improvements in user experience in future distributions.