[haiku] GSoC project: application updater
- From: Henri Vettenranta <henri.vettenranta@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Wed, 01 Apr 2009 19:38:42 +0300
I've been thinking about submitting a GSoC application to develop an
application updater for Haiku. I've taken ideas from Linux package
managers but also from Secunia's PSI software¹ for Windows. However
unlike a package manager, the updater will not take part in the initial
installation of the application or in the removal of old applications no
more in use. Unlike PSI, the updater will use information provided by
the application authors themselves instead of relying on a list of
applications provided by myself or some other third party. Also by using
file system attributes and indexes it should be possible to avoid
lengthy file system scans like those PSI does.
¹ http://secunia.com/vulnerability_scanning/personal/
The application updater will show a list of applications found on the
system that can be upgraded or updated, and maybe end-of-life
applications as well. Using attributes an on-disk database of installed
applications can be avoided. The idea is also to cause no harm to people
who do not use the updater so that special updateable and non-updateable
versions of applications do not need to be provided.
Each application that wishes to show up in the updater will have a url
attribute that tells the application updater where to download a
database of the applications of a single vendor. This database is a
simple text file that describes all the applications of the vendor, the
newest versions of these applications, and the versions of an
application that are known to be insecure. The file may also list
upgrade paths to different major versions, or maybe to different pieces
of software altogether.
Other information that needs to be available in attributes is a unique
identifier for each app, and the major and minor version of the
application. Looking with QuickRes at some applications, they seem to
have a 680-byte-long BEOS:APP_VERSION attribute, but its contents don't
look like they could be used by the updater. The application signature
looks like a good candidate to use as the unique identifier, though. I
also wonder whether a major version attribute is needed, or whether it's
feasible to have different application signatures for different major
versions. In this case the upgrade path could be used to direct the user
to a new major version when the currently installed version is obsoleted
and no minor updates are provided for that anymore.
One problem will be finding all the applications installed on a system.
Since just scanning all drives is not feasible, this should be done by
using an indexed attribute. One idea is to search for files whose type
is application/x-vnd.Be-elfexecutable, but my concern is applications
written in Python or some other interpreted language; are they of some
other type? Also I'm not sure if it's better to label the executable
file or the application directory with the updater attributes. The next
idea that comes to mind is to index the url attribute, although in this
case indexing its contents is pretty useless since it's the existence of
the attribute that is searched for.
Once the user commands an application to be updated, the updater will
download a zip file from a location specified in the application
database file and extract that over the directory where the application
is installed. Using a statement in the database the directory may be
emptied before extraction, but I think updates requiring more complex
actions should be manually done by the user. For these complex cases,
and in the case of upgrading the app to a new major version or another
application altogether, the database may specify a web location that is
opened in the user's web browser. The location may also be used to
advertise an upgrade to a commercial application the user has, but I
think the updater should have an option for the user to avoid these
kinds of ads if he wants to.
My last concern is whether designing and implementing this kind of an
application is the right size for a GSoC project. If it's too small
there's the possibility of adding SoftwareValet package and install
script support, maybe dependency handling in case a new major version
requires libraries the old one didn't. These all make the application
more complex, however, so their trade-offs should be thought of
carefully.
Any comments and suggestions are appreciated, although I'll start
writing the application now. I know I'm already pretty late, but I've
been kept busy by studies for the last few days.
--
Henri Vettenranta
HeTo
Other related posts:
