Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Distributing software with RiscPkg

By Theo Markettos. Published: 22nd Feb 2005, 15:39:41 | Permalink | Printable

Essential How-to for developers

In a previous article, Graham Shaw outlined what the RISC OS Package Manager is and how it can be useful for finding software and keeping your system up to date. But how do developers package up their software to be used by the system? By packaging and distributing your software with RiscPkg, your users won't have to worry about headaches like installation, downloading the latest support modules and keeping their software up to date. In this article, Theo Markettos aims to find out just how painless it is

RiscPkg motifLike most RISC OS software, RiscPkg packages are distributed in the form of Zip files. However RiscPkg packages have a fixed structure which enables the package manager to automatically install, upgrade, or remove the contents to or from your machine. This is described in the RiscPkg policy manual which is the ultimate reference on how to create a package, but I shall outline the process here.

In addition RiscPkg supports both binary (the finished program) and source packages. Whilst support for source packages isn't fully complete, in future it will be possible to automatically compile source packages into binary packages, with the result that improvements in compilers or libraries can be rolled out across the entire package database overnight. Imagine how much easier it would have been on the introduction of the Iyonix if all C programs had automatically been rebuilt 32 bit compatible just like that. Of course this doesn't apply to every program (some need human intervention to upgrade the build environment, others in BASIC need no compiling at all), but once finished the feature will be there if it's needed. The Netsurf and Unix Porting projects make use of a similar feature - so updates are automatically reflected in the distribution versions.

Before we start, you'll need a copy of RiscPkg. So download a bootstrap version from RiscPkg Central. Now RiscPkg needs to fetch itself, so run the version you've downloaded, open its window and choose 'Update' from the menu. RiscPkg will fetch a list of packages it knows about. One is RiscPkg - click menu over this and choose "Package 'RiscPkg'->Install". Then choose Commit and a full version of RiscPkg will be installed in Apps.Admin at the same level as !Boot. You can now delete the copy you downloaded earlier. By default RiscPkg puts programs in the <Boot$Dir>.^.Apps - if you don't like the paths where applications go, change them in !RiscPkg.Resources.Paths.

It should be noted that here I describe the full package format - if only trying it out and you don't use the central archive of packages you only need a Control and a Copyright file - but I'll describe some of the features of the full package format along the way. If you want to get involved in packaging, join the mailing list at RiscPkg Central.

A sample package
I've created a sample package based on the classic programming example Hello World. This can be found here. Let's look at the contents of the Zip file. Ours has four directories at the top level: Apps, RiscPkg, Sprites and SysVars.

Firstly we have the program itself, !Hello, which may be found in Apps.Programming in the zipfile. So that RiscPkg can keep track of where everything you've installed has gone, it stipulates certain hierarchies where types of files can go. In this case, Apps indicates it contains an application. Anything below this is specified by the person maintaining the package, so as maintainer I decided that !Hello should go in Programming. If we imagine thousands of packages might be installed by this system, it's best to keep a clean hierarchy.

Thumbnail of Package structure
Layout of our sample RiscPkg package (Download Drawfile version)


If we have documentation which we don't feel should go in the application directory (perhaps our package only contains documentation) we can put it in a top level Manuals directory, but we don't have any in this example.

We must provide information on the licence conditions of our program in a file RiscPkg.Copyright. This states who owns the copyright, where the maintainer obtained the program and the licence it is under.

System variables and sprites
There's nothing special about !Hello, it's just a normal RISC OS program. RiscPkg only cares about the !Run, !Boot and !Sprites files. !Hello does two things: it says hello in a window, and also provides a command *Hello.

So that we don't have to put !Hello on Run$Path, which would cause Run$Path to become very long if every application did it, we set an alias for *Hello to point to the program inside the pplication. RiscPkg specifies that every *command must be implemented in this way. !Hello's !Run file may be seen below

| !Run file for Hello World RiscPkg example
Set Hello$Dir <Obey$Dir>
Set Alias$Hello <Hello$Dir>.!RunImage %*0
TaskWindow -quit -wimpslot 16k <Hello$Dir>.!RunImage


RiscPkg takes special care of system variables and sprites. Applications must specify which variables they use to RiscPkg and their contents by putting them in a textfile in the SysVars directory of the Zip file. This contains one file for each system variable, each holding the value of the variable. For example, Hello's has SysVars.Alias=24Hello which contains:

<Packages$@Apps.Programming.!Hello>.!RunImage %*0

The idea is that the part in angle brackets is replaced with the actual path of the program on disc when our package is installed, so that we don't have to go around opening Filer windows on hundreds of programs before we can use them. Think of this as RISC OS 4 !Configure's 'Look at' feature, except every program is automatically looked at on startup. Since some characters are not allowed in filenames, we must replace full stop (.), colon (:), dollar ($), ampersand (&), at-sign (@), caret (^), percent (%), backslash () and equals (=) with their hexadecimal value preceded by = as in Alias=24Hello (instead of Alias$Hello).

We do the same for Hello$Dir, the other variable that is set by !Run. !Hello also includes a sprite !hello which we merge into the Wimp sprite pool. RiscPkg also keeps track of sprites, so in the Zip file we have a Sprites directory, which contains one file for every sprite that a package provides to the Wimp pool. So we have a textfile Sprites.!hello (in current versions the filename is case sensitive), which contains:

<Packages$@Apps.Programming.!Hello>.!Sprites

You might say that RiscPkg managing system variables and sprites is superfluous if they've been properly registered with RISC OS Ltd. On one view it is, but remember that RiscPkg takes care of the bigger picture. What if two applications provide an icon for the same filetype? Or several packages provide different implementations of the same command (BSD Make, GNU Make etc)? RiscPkg needs to know about this.

!Boot is similar to !Run:

| !Boot file for Hello World RiscPkg example
If "<Hello$Dir>"="" Then Set Hello$Dir <Obey$Dir>
If "<Alias$Hello>"="" Then Set Alias$Hello <Hello$Dir>.!RunImage %*0
IconSprites <Hello$Dir>.!Sprites


One thing to ensure is that !Boot never changes variables if they're already defined. There's nothing worse to find that opening a Filer window on an old backup overwrites variables causing the RISC OS 2 copy of an application to run instead of the latest version elsewhere on your system. Ideally this should happen with sprites too, though it's difficult to achieve.

RiscPkg control file
Also in the Zip file lives RiscPkg's control file, which are the key to telling RiscPkg about your application. These is a text file RiscPkg.Control in the Zip - for Hello it has:

Package: Hello
Priority: Extra
Section: Programming
Maintainer: Theo Markettos <theo@markettos.org.uk>
Standards-Version: 0.0.0.0
Version: 1.0-0
Licence: Free
Description: A classic program, and an example RiscPkg
 Hello provides a classic computer science program. It also demonstrates
 how to construct a package for RiscPkg.


These are all detailed in the Policy Manual, but briefly:

Package
This is the name of the package.
Priority
The importance of the package. This has five levels from Required (necessary for the system to work, eg SharedCLibrary), through Standard (default for a typical user, wanting a small but not too restrictive system, eg Nettle) to Extra (packages with a very narrow audience). Since not that many people are going to want to use !Hello or create packages, we set it to Extra.
Section
The purpose of the package, which may be Admin, Library (for programming language libraries), Module (RISC OS modules), Programming or Misc (everything else). Other sections may be added in future. !Hello is a programming tool, so goes in Programming.
Maintainer
The name and email of the person who created the package, who may not be the original software author.
Standards-Version
The version of the RiscPkg Policy Manual referred to when constructing the package. The current version is 0.0.0.0. The last digit refers to insignificant changes in policy (perhaps corrections of spelling errors in the document), so we only specify version 0.0.0.
Version
The version of the package. This is designed so that when sorted, later version numbers appear after earlier ones. It is composed of three parts as epoch:upstream-package. The upstream version is that of the program as received from the original developers, for example GCC 3.4.4. The package version is the number of the package: you may update the package control file, for example, and this enables you to provide an updated package without altering the upstream version. The sorting ensures that 2.4.9 comes before 2.4.10, and -, +, . and : are allowed in version numbers. The package version is separated from the rest of the rest of the number by a final dash. The epoch is present if it is necessary to replace a larger number with a smaller one - as GCC 2 turned into EGCS 1 which became GCC 3, for example. Here we have !Hello version 1.0 and this is package version 0.
Source
The name of the source package from which this binary package was generated. In this case we don't have a source package so we omit this line.
Licence
This is either 'Free', meaning packages that meet the Open Source Institute's definition of Open Source, or 'Non-free', that do not. Note that this refers to freedom, not price.
Description
A short description of what the package is follows this tag. A longer description can be included on successive lines if indented by a space.


Dependencies
Now we get on to one of the key features of RiscPkg. A package can specify other packages on which it Depends (requires), those it Recommends and Suggests. For example:

Package: Netsurf
Depends: WindowManager (>= 3.98), SharedUnixLibrary (= 1.02-1), Tinct
Recommends: Fonts-Unicode (>> 0.01)
Suggests: Printers


Here Netsurf can't work without at least version 3.98 of the WindowManager package (any package version), exactly upstream 1.02 package version 1 of SharedUnixLib and any version of Tinct. Most users will want to install Fonts-Unicode (a later version than 0.01), but it's not obligatory. Finally users could install Printers with it, but Netsurf will work perfectly well without it.

So if you choose to download this Netsurf package, it'll automatically pull in the packages it depends on. RiscPkg can also prompt you whether you want to install the recommended or suggested packages, though it doesn't yet.

On the other hand, there's the Conflicts tag. If we had:

Package: MimeMap-JustinFletcher
Conflicts: MimeMap-RISCOSLtd
Depends: SysLog


it means that only Justin's MimeMap or only RISC OS Ltd's MimeMap could be present on the system at once. So if you tried to install ROL's, RiscPkg will ask you whether you want to remove Justin's. Imagine you had another package that needed a specific implementation:

Package: CDFS
Version: 0:roselect-2.67-3
Depends: MimeMap-RISCOSLtd


Then installing this CDFS would pull in ROL's MimeMap too. But if you already had Justin's installed, RiscPkg would have to uninstall that before it unpacked ROL's. And since dependencies are recursive, CDFS installing MimeMap will bring in SysLog too.

The idea being that you don't have to remember to get all the programs a package needs. RiscPkg is heavily based on Debian Linux, where you can just type...

apt-get install mozilla

...and it goes away and gets the many packages that make up Mozilla, installs them and configures them, asking any pertinent setup questions along the way.

Package list
So we zip all that lot up and put it on a webserver. It's a good idea to call the zipfile by the package name and include the version, so I have Hello_1.0-0.zip Now we have to tell RiscPkg what packages we have available. We do this by creating a text file Packages which contains the concatenated Control files of each package separated by blank line. You can see RiscPkg's master Packages list at www.riscpkg.org/pkg/Unstable. So RiscPkg knows where to find the packages we add three lines to each entry in the Package file:

Package: Hello
Version: 1.0-0
...other entries in the Control file...
URL: http://www.drobe.co.uk/extra/riscpkg/Hello_1.0-0.zip
Size: 3540
MD5Sum: 474ca4f9b400ec9571b559113bd82f5b


This tells us the URL of the package file and its MD5 sum so we can check it hasn't been corrupted on download. The command line tool md5sum can be found in the CLI section of the Unix Porting Project.

Installing our package
We could get our package list integrated into the main RiscPkg packages file, so everyone can download them. But RiscPkg can cope with multiple places to look for package lists, so instead we can upload our package list to a website, say http://www.drobe.co.uk/extra/riscpkg/Testing and add a line in !RiscPkg.Resources.Sources like:

pkg http://www.drobe.co.uk/extra/riscpkg/Testing

Next time we tell RiscPkg to update, it'll fetch this file and allow us to download the Hello package. To do this, load RiscPkg and then use exactly the same process as you did to install the full copy of RiscPkg itself. You'll find Hello in $.Apps.Programming as we told it.

If I release a new version of Hello, or any other maintainer releases new software, an upgrade is simple. Run RiscPkg, choosing Update, then Upgrade then Commit. Three menu clicks to keep your entire system up to date. What could be easier?

Links

RiscPkg website

Previous: Acorn Cybervillage update shocker
Next: South West show warm up

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Wow! A lot of work to be done and is being done on RISC OS. The RISC OS Package Manager seems to be an important feature we need? Looks great.

 is a RISC OS UserSawadee on 22/2/05 8:00PM
[ Reply | Permalink | Report ]

Hm, I don't like the trend towards having lots of dependencies. IMHO one of the biggest strengths of RISC OS was always, that applications were (mostly) entirely self-contained (right word?) in their application directories. That way installation was down to copying the app-dir to your hard drive and de-installation was done by simply deleting the copy from the hard drive.

I know that since the introduction of choices directories and shared libraries this became slightly different, but it was still easy to simply keep the SharedCLib up to date and resetting the choices for an application was simply done by deleting its choices directory inside !Boot.

In the end it comes down to this: Package managers help you to keep a complex system up to date with little effort, but the price for this is, that you loose the feeling of having complete control over your system.

 is a RISC OS UserJGZimmerle on 22/2/05 8:26PM
[ Reply | Permalink | Report ]

You might not like it, but RiscPkg is only reflecting the realities of modern RISC OS software. There have been many many problems during 2004 with people having out of date or incomplete dependencies - NetSurf is a good example, but there are others.

If you have a loose feeling, then you might like to tie it down.

 is a RISC OS Usermrchocky on 22/2/05 9:24PM
[ Reply | Permalink | Report ]

The RiscPkg policy manual link seems to be broken - as far as I can tell it should be [link] (which does work).

 is a RISC OS Userhutchies on 22/2/05 10:06PM
[ Reply | Permalink | Report ]

I have to agree with Julian - I go to a bit of effort to try and make our apps self-contained, and it definately reduces the support burden, whilst generally pleasing customers. I can, however, think of quite a few instances where it would be worthwhile, so huzzah to all involved (smile)

 is a RISC OS Userarawnsley on 22/2/05 11:24PM
[ Reply | Permalink | Report ]

mrchocky> Surely those problems occurred precisely /because/ dependencies have been created. If, instead, NetSurf - for example - came with its own copy of the modules that it uses (Tinct being the obvious example), inside its own app directory, the potential problems would be fewer.

I'd love to believe RiscPkg could be a panacea but I'd wager that - just like InstallShield, Add/Remove Programs etc on Windows - we'll just end up with a more complicated system that still confuses the user with "<file/package> not found" or "<cryptic filename> is no longer being used; delete it?" messages.

IMHO the self-contained application directory, which can be treated as indivisible and copied/moved manually is a superior design; at least until such time as the user cannot manually add, edit or remove software without the package management being aware of the changes.

 is a RISC OS Useradrianl on 22/2/05 11:47PM
[ Reply | Permalink | Report ]

adrian: I thought as a developer, you would know a lot better.

Of course the depedencies have been "created" - as I said, that's a consequence of modern programming tecniques and user demands - I'm not really sure what point you're trying to make by this. As you know full well, hiding nominally shared modules inside applications - especially modules that change regularly - creates a time bomb for problems later on with modules of various versions spread around a system. There was even a lengthy discussion on the NS mailing list as to why this was a really really bad idea.

In any case, it would be naive to suggest that modules are the only kinds of dependencies. Once we have shared libraries they will require this dependecy functionality - but there are already many kinds of dependencies in RISC OS, and many ways in which dependencies can be used to help out the user.

No one's claiming it's a panacea, but you most certainly shouldn't draw comparisons with Windows. It doesn't use a model that's very close at all to this. Look at the Debian system instead - there, packaging solves an astonishingly large number of problems - in fact, packaging is the reason Debian is so popular. As for crytic messages, there's no reason at to expect them to exist in a RISC OS program - if they do, then we can expect users to complain very quickly.

 is a RISC OS Usermrchocky on 23/2/05 8:26AM
[ Reply | Permalink | Report ]

To an extent the benefits/hindrances of such an approach depend on the individual applications that use them.

Certainly for critical applications the design strategy is too keep the application as self-contained as possible, minimising the risk caused by third party components failing. With such applications, testing is paramount. It is usually difficult to rigourously test 3rd party components, and even more difficult to design a system that can cope with future changes to these components.

In general, however, it is recognised good software practice to develop systems that have high cohesion and low coupling between respective components. High cohesion means that the different components should have a close logical relationship, low coupling means that components should not be tightly intergrated (the components are almost independent).

 is a RISC OS UserWalks on 23/2/05 10:16AM
[ Reply | Permalink | Report ]

For anyone who wants to see previous debate on this topic, see [link]

 is a RISC OS Usercaliston2 on 23/2/05 11:26AM
[ Reply | Permalink | Report ]

mrchocky> If an app A contains its own copy of module/library M then it will surely continue to work with that version of M.

The only 'timebomb' is surely when app A is already running and the user tries to start app B which requires a later version of M and the loaded M cannot be unloaded. (The classic example is CLib, of course; this used to happen on RO2.)

Having a shared library system could (and should IMHO) allow each app to use its own version of M, thus avoiding compatibility issues as well as dependencies.

Oh, and I'd contend that even "'A' requires version 0.09 of M or later" is a cryptic message to most users and - on a personal note - I find it irritating to have to go searching for modules/libraries (of unknown purpose) on the net (or on discs) to nudge A slightly closer to starting up. (I say that because you'll often have to go looking for more than one thing, ie. repeating this process until the app starts.)

I think a lot of 'technophiles' and developers quite enjoy the challenge of installing and configuring software (it's like wiring up your hifi, your DVD player, tuning your TV etc). Me, I want a big red button marked 'Go' that actually works, and I suspect there are more of us in the latter camp.

I appreciate that package management aims to build that red button, but as long as it's used by only some apps, and as long as it remains unaware of some changes, it will be just another button and you don't simplify a system by adding buttons.

Lastly, you said "...a consequence of.... user demands." Can you explain that please?

 is a RISC OS Useradrianl on 23/2/05 11:26AM
[ Reply | Permalink | Report ]

adrianl: Having different versions of the same thing scattered throughout your hard drive doesn't seem all that good an idea to me.

"... but as long as it's used by only some apps, and as long as it remains unaware of some changes, it will be just another button and you don't simplify a system by adding buttons"

That is an argument for never trying to fix anything. Better to try, and if a solution works well then hopefully it'll end up being adopted by most developers. A period of confusion when old and new overlap is sometimes a price you have to pay for progress.

Still, I somewhat agree with you, since installing a RISC OS application has, for me, rarely involved more than "drag app out of archive into where I want it, and possibly update !System." A complete packager sounds like overkill for RISC OS.

 is a RISC OS UserSimonC on 23/2/05 11:58AM
[ Reply | Permalink | Report ]

I've been thinking about releasing DirSync and SpamStamp as RiscPkg packages for some time now, but never had (took) the time to investigate the possibilities. Yesterday I read the article, and it may well initiate such a process for me.

However, as I see it now (but it was late when I read the article, so I may have missed something), both DirSync and SpamStamp have some challanges that I don't really see how they should be resolved.

First, DirSync uses Simon Birtwistle's theme-stuff (IconTheme I think it was called, can't check since I'm at work), which means it gets different icons for RO3, RO4 and RO5 (since the icons are based on the directory-icons of the RISC OS version that is used). How would that work in RiscPkg?

In different releases of SpamStamp there has been the need for conversion of hashtables and such things. These have not been things that I wanted to do automatically, so there is some user-action involved. How would that work in RiscPkg?

Is there a need to supply these types of applications by RiscPkg, since they are pretty self-contained? I expect the answer is yes, but I ask anyway... Thinking about it, DirSync contains plugins, which could of course then be released and updated separately. SpamStamp is dependent of 'a mail system', but not a specific one. Is that a dependency in this context? How would that be defined?

 is a RISC OS Userjjvdgeer on 23/2/05 11:58AM
[ Reply | Permalink | Report ]

adrian1: Sadly, I find your attitude dimissive of the clear problems faced by RISC OS users - head in the sand isn't going to solve anything.

I can't agree at _all_ that distributing different versions of modules with an application is a good idea. This has proved disastrous in the past, and to continue to think the existing RISC OS situation is ok is the path to mediocrity for RISC OS not to mentioning increasingly difficult upgrades (which are often already hard enough now).

Whether or not there's a requirement for an application to use a different version of a shared library (which is actually pretty rare) is irrelevant to this, and is simply a feature of the shared library system. They _must_ be provided as dependencies. Anything else means we are completely wasting our time with shared libraries.

I find your anology with buttons broken. There are already vast numbers of buttons to push into order to install (for example) NetSurf. The point is to make this a one step process. There's no reason why it can't be. Don't dismiss RiscPkg just because it has issues at present - they can be resolved.

And finally, again, forgoodness sake, don't stick your head in the sand over this. Upgrades have become a severe problem for RISC OS, even if most of the time it's "ok". Persisting with the present situation isn't possible - even if it's only because it's such a sap on developer time.

 is a RISC OS Usermrchocky on 23/2/05 12:36PM
[ Reply | Permalink | Report ]

jj: for your icon dependency, you'd depend upon a virtual package. The icon packages would provide the functionality asked for by the virtual package. The user could then select one package which meets this dependency - or there could be some kind of OS specific package selection mehcanism.

As for SS upgrades, I would have to know more about what's required to properly comment, but there are a number of solutions. If you want to keep the process manual, then the easist solution is so simply prompt the user to do the reuired actions after a new version is installed and run for the first time.

Yes, the plugins could be in different packages, but there might not be a great need to do that. Yes, SS could too rely upon a virtual package which provides mail functionality, although at this time, no such package exists, so perhaps best to leave it out for now.

 is a RISC OS Usermrchocky on 23/2/05 12:43PM
[ Reply | Permalink | Report ]

I still don't understand what is wrong with the existing sytem of having a central !System application wich contains all shared components and the otherwise self-contained apps. As long as all apps supply a dummy !System application containing all the shared components they need, the installation would simply consist of merging the dummy !System by dragging it to its !Configure plugin and copying the app.

 is a RISC OS UserJGZimmerle on 23/2/05 3:29PM
[ Reply | Permalink | Report ]

From what I understand, package management is a fix for a problem: dependencies. There are some serious downsides to the use of package management compared to the simpler method of having everything in a !App directory:

- Programs no longer run directly from the medium they are supplied on (e.g. CD or within an archive). - Programs can no longer be shunted around the hardrive at will by the user. - There is a lack of transparency from the user's point of view (they don't necessarily know what is going where).

In my mind it will be sad to lose such functionality, especially as in some sense it "defines" RISC OS. However, it seems the suggestion is that this is a necessary step that must be taken if we are to allow more dependencies between programs. Particularly important if we are going to allow the porting of programs easily.

So whilst it's sad, I applaud the developers for tackling the problem head on. With luck the pros will outweigh the cons.

 is a RISC OS Userflypig on 23/2/05 3:59PM
[ Reply | Permalink | Report ]

Right _now_ programs have to be in a fixed location, but I have a variety of ideas to remove this restriction, so please would people not keep mentioning this as a real deficiency. There will be some neccessary restrictions so it doesn't get too silly, but nothing onerous.

JGZ: that method is all very well - except that many apps don't fit into that mould. It doesn't apply for example to other !Boot updates, nor to command line applications, nor really to say, any random files.

As for dependency handling - yes, that is very important - but the other important bit is ensuring ready notification and install of new versions of software = currently a very manual process.

 is a RISC OS Usermrchocky on 23/2/05 4:07PM
[ Reply | Permalink | Report ]

mrchocky:

"I have a variety of ideas to remove this restriction"

Good news. I'm sure this will make for an easier transition for many users, and will also reduce the support burden that would otherwise inevitably result from users moving their applications and finding they no longer update properly.

 is a RISC OS Userflypig on 23/2/05 4:59PM
[ Reply | Permalink | Report ]

It is important that we programmers realise that end users couldn't care less about shared this, and packaged that. They want a program which they stick the disc in (metaphorically) and use. As long as this is achieved, it's all good. Just this morning I had a chap on the phone who'd never installed his copy of oregano (or had tried and failed) because of the !Boot updates, and things he felt he needed to download. This type of story isn't isolated.

The key is that either via self-contained apps (often the best way) or via installer programs (eg. RiscPkg, and most useful when an application necessarily installs itself in various places) the end user has a smooth ride.

Citing an R-Comp example, UniPrint necessarily installs bits all over the place (it has to hook into the printer manager, install definition files, and start a support module at boot time). For this, I wrote a simple installation application that serves to both install and upgrade/update the software. This may well have been made easier by RiscPkg, I don't know. But the end result is smooth for the user, and that's what matters.

 is a RISC OS Userarawnsley on 23/2/05 7:00PM
[ Reply | Permalink | Report ]

One dependency that it's very easy to fall foul of is that of producing Draw, TextEase or TechWriter files, for example, that use fonts other than those in ROM. Distribute them at your peril ! In Draw you can, of course, convert them from fonts into paths but it is easy to forget to do so. I was interested to see that the packaging project (in the example in the article) attempted to warn of the fonts required/expected.

 is a RISC OS Usermartin on 23/2/05 7:24PM
[ Reply | Permalink | Report ]

ar: "we programmers". Sorry, what? I don't really think you've ever done a significant amount of programming to try and speak for RISC OS developers in that respect and you've never really contributed to any RISC OS programming forum. Simple scripts are a long way removed from serious development.

As for the users, I'm quite certain they _do_ care about dependencies - whether or not they specifically call them those is another matter, but users understand them extremely well (Look at Debian users if you don't believe me). The one mentioned above where a specific icon set is required is a good example, but there are many many more - probabaly a great deal more than are immediately obvious.

As for specific installers and UniPrint - that's all very well of course, and there wasn't the choice of RiscPkg at the time - but what happens when you want to uninstall it? Or it gets upgraded and files move around - can you be sure you removed all the old files?

martin: that's an interesting problem, but perhaps not one that RiscPkg should or can address - the reason is that it really concerns itself with programs - rather than program output - although there are exceptions.

 is a RISC OS Usermrchocky on 23/2/05 8:16PM
[ Reply | Permalink | Report ]

ar: The 'installer' you distribute could be a dressed up version of RiscPkg and the software supplied in zipfiles that just happen to be RiscPkg archives. So you run !Install, it finds the packages you've supplied on the CD and installs them. It just happens to use RiscPkg (or more likely libpkg) as a backend, so it keeps track of the packages it's installed. Since they have version numbers that match the packages that are freely available, if a newer version is available on the net the user will grab it next time they run RiscPkg. And if they already had a newer version on disc than is on your CD, it's not replaced by the old one. You could also create packages for all your proprietary programs, so that (given suitable authentication) next time the user runs RiscPkg it offers to download upgrades from your server.

chocky: I think you and Andrew are saying the same things. Users do care about dependencies - but sometimes they're scared by them. I think the majority of Windows users wouldn't be able to do much more than click Setup.exe to install. We mustn't forget that a large number of people are relatively computer illiterate and not force them to know too much about what's going on.

 is a RISC OS Usercaliston2 on 23/2/05 9:30PM
[ Reply | Permalink | Report ]

Don't you people read first before you reply in a rather offensive way on something that was not said? BTW. programs care about dependencies, users don't until their programs complain.

 is a RISC OS UserJaco on 23/2/05 10:07PM
[ Reply | Permalink | Report ]

calliston2 - you're exactly right, it would do what I need (I think I said as much) and I read the article with interest, and plan on checking it out. As you say my point (which may have got lost) is that as long as software goes in, works and does the job, the end user is happy. Of the couple-of-thousand RISC OS users left, the bulk of them regard themselves as relatively non-technical.

Peter, I'm truely sorry if I insulted you by classifying you in the programmer bracket. Thanks for correcting me.

 is a RISC OS Userarawnsley on 23/2/05 10:12PM
[ Reply | Permalink | Report ]

andrew: does being flippant add more credibility to your points? You're welcome to categorise yourself as a programmer, but I'm looking hard to see any work you've done. If you do, I'm happy to take on any other suitable naming you care to give. I've only been doing it for 20 years.

theo: being scared - that's part of the problem - especially for example with the existing situation with NetSurf. I think a proper RiscPkg implementation will make this far less scary, and graphically display dependencies.

Jaco: users _do_ care - for reasons I named, and many many more. But they might not immediately recognise things they care about as package dependencies.

 is a RISC OS Usermrchocky on 23/2/05 10:19PM
[ Reply | Permalink | Report ]

mrchocky:"Look at Debian users" Um, no. Since when does RISC OS=Debian? It's easy for programmers who are familiar with package management to see its power and usefulness. But just because it's right for Debian doesn't mean it's right for RISC OS.

Personally, I like the sound of RiscPkg as a centralised resource for downloads/updates but am not convinced (like JGZimmerle) of the need for an installation solution beyond !System+!MyApp.

Of course no one's going to be forced to make use of it - so it's no biggy :-)

Adam

 is a RISC OS Useradamr on 24/2/05 10:01AM
[ Reply | Permalink | Report ]

Some thoughts - to summarise 1. I like the simplicity of drag and drop installation anf simply deleting a directory to uninstall. It is one of the advantages of using RISC OS. 2. This is all well and good, but for applications with complex dependencies such as those ported from other platforms that assume a suitable package management system, manual installation can reuire a good deal of technical knowledge from the user. Thids is clearly not on, so a means of automatic installation is abolutely essential if initiatives like Peter's Unix Porting Project are to produce anything significant suitable for installation by the non-technical. Having seen how complex some installations can be under Linux, it could be all but impossible to get it right without a good package management system. 3. Given that we need a form of automatic installer, a centralised system is much better than developers trying to write individual installers for their applications, saving development effort and providing consistence for the end user. We are fortunate that Graham has taken on this task. 4. One problem with such programs is that they really need to have knowledge of everything that is installed on the machine. This means that either everything must have been installed using the package manager, or the package manager must have a reliable way of discovering what is installed by other means. If we could achive the latter, then it would'nt matter that some things have been installed by drag and drop. I think that sorting this out is one of the major challenges to be faced in developing a package manager for RISC OS.

 is a RISC OS Usermrtd on 24/2/05 10:02AM
[ Reply | Permalink | Report ]

If people are going to talk about 'users' they should specify what type they are referring to.

The vast majority of users will be end users with basic computer knowledge. All they will be interested in is that an application installs smoothly, and if they decide to uninstall it, removes itself from their computer. They won't care about dependencies because they don't know about them.

Developers or more technical users, on the other hand, are more likely to be aware of dependencies and so it may be more of a concern.

However, as I pointed out earlier, it is bad software development practice to develop applications that contain many dependencies to third party components that are outside of your control.

 is a RISC OS UserWalks on 24/2/05 10:15AM
[ Reply | Permalink | Report ]

admar: "Um, yes". At no point has anyone said or claimed that RISC OS is Debian. All that has been said is that the Debian model of package management is really quite close to what's required for RISC OS (and as I _also_ said, there are some very important differences). These are conclusions that Graham, myself and others came to after extensive consideration of the matter. Additionally, I would claim that non-technical Debian users understand dependencies very well, and that RISC OS users also do.

 is a RISC OS Usermrchocky on 24/2/05 10:29AM
[ Reply | Permalink | Report ]

mrtd: It will be a long time before there are enough things packaged to have a complete system under package management. But I don't think this is a real problem under RISC OS, as applications tend to be confined to their own application directories. This is in contrast to Unix setups where files for a program may be spread across the filesystem.

Walks: again, I insist that users (however you define them), understand dependencies very well. Even if they didn't, I don't think it would be a genuine concern for RISC OS package management.

As for software engineering practices - yes, of course. However in many cases we have to deal with decisions about cohesion and coupling that were made many years ago. Fortunately there are a variety of mechansims that let us deal with these. In particular, the Suggests, Recommends and Provides control statements of packages.

 is a RISC OS Usermrchocky on 24/2/05 10:37AM
[ Reply | Permalink | Report ]

One way of looking at RiscPkg is it's a (semi-)centralised archive of software like HENSA was. But it just happens to be designed in such a way that it can also automatically install. So if you really want to install everything manually, it's no different from downloading stuff from HENSA or the author's website. It's just a bunch of zipfiles after all. But if you would rather your machine took charge of installation then you can do that too. It just means a reduction in the higgledy-piggledy way software is packaged and distributed at the moment.

Remember that you don't actually lose much control over the current situation. Applications are still applications and largely self-contained, and there's nothing to stop you deleting a RiscPkg managed application. You'll just have the same consequences as now if other things depend on it - in fact it's better than that because the database says what depends on it. Even if applications are forced to be stored in a certain place (perhaps not the case in future) then it's no too hard to create link applications (like AddApp does in Resources:Apps) that you can keep whereever you like to run the program. And at the end of the day the package state is still visible, so if you really want to convince RiscPkg that version 99 of GCC is installed, you just have to change the database textfile. Whilst none of these things are recommended, in the same way that fiddling witht the inside of !Boot isn't, nothing is stopping you if you insist.

 is a RISC OS Usercaliston2 on 24/02/05 11:14AM
[ Reply | Permalink | Report ]

Oooh, an example. I installed Adjust a few months ago. As a power user, did I a) want everything taken care for me by the installer or b) want to do it by hand? I prefer a) because it meant I didn't have to spend half a day tweaking things to bring over all my previous configurations manually. The installer just did what it was supposed to do and I could make a cup of tea. This is what computers are good at - tedious repetitive tasks - and whilst it's nice that it's transparent so I can see what's happened if I really want to, I shouldn't have to open the bonnet every time I want to drive the car.

 is a RISC OS Usercaliston2 on 24/02/05 11:23AM
[ Reply | Permalink | Report ]

I'm writing here as a user. I absolutely hate dependencies. While some may be necessary, I think they should be kept to a minimum, and maintained in a user friendly way. So I guess this means the packager could be a really good thing. I don't think it will affect most programs, with no dependencies, at all. I just hope it won't develop into a windows-like registry, which would be a nightmare. (I think this is probably what most people are worried about.)

MrChocky, being flippant may not add credibility, but it is fun. I'm sure there really is no need to be so abrasive, I don't think that adds weight either. (Yes I know, pot && kettle, but I do try.)

 is a RISC OS UserLoris on 24/02/05 12:12AM
[ Reply | Permalink | Report ]

Select/Adjust is a good example yes. The Select installer is very good - mostly being concerned with the Boot, and all the strange things people do to it. One of the things that isn't really handled is the other applications - Paint, Draw, etc. Fine, if they're in standard places, you can drop the archives over the top. If not, then you have to drag them out individually. In many cases, the app might have not even changed. It's this kind of piecemeal upgrade that RiscPkg will be good at.

Another point, related to the HENSA example. Let's assume for the moment that RiscPkg doesn't handle dependencies, and is just a method for a unified method of downloading the latest versions from disparate places. Even _this_ would be a huge time saving for users.

But even in a properly managed dependency environment there may be room for this - say for documents you don't want to keep = RiscPkg would download them, and then present you with a zip (or open zip) to let you drag it to your RAMDisc. Perhaps that's not a great example, but you get the idea.

 is a RISC OS Usermrchocky on 24/02/05 12:13AM
[ Reply | Permalink | Report ]

In reply to Tony: I don't think that there are many programs with no dependencies at all. Even "Hello World" will have dependencies although they aren't listed in the example above. C programs can't even print a line of text on the command line without using a "library", albeit one that hardly ever changes. Other libraries or modules such as the Toolbox will be used if the WIMP interface is any more than trivial (and there ARE alternative versions of the Toolbox). Even OS functions in the ROM constitute dependencies, so unless your program pokes the memory directly to do its I/O, it will have dependencies.

 is a RISC OS Usermrtd on 24/02/05 12:58AM
[ Reply | Permalink | Report ]

mrchocky:"At no point has anyone said or claimed that RISC OS is Debian." I realise that. In a comment discussing whether users know/care about dependancies, you said "Look at Debian users if you don't believe me". My point was that "looking at Debian users" tells us nothing about RISC OS users.

"Let's assume for the moment that RiscPkg doesn't handle dependencies, and is just a method for a unified method of downloading the latest versions from disparate places. Even this would be a huge time saving for users." Absolutely :-)

Adam

 is a RISC OS Useradamr on 24/02/05 12:59AM
[ Reply | Permalink | Report ]

adamr: and why does it tell us nothing about RISC OS users - on what basis are you making your assertion? It tells us a great deal. Unless of course you are asserting that RISC OS users are thicker than typical non-techincal Debian users? I can name numerous situations which are the same or very similar on both - it's quite clear there are plenty of conclusions to be drawn.

 is a RISC OS Usermrchocky on 24/02/05 1:46PM
[ Reply | Permalink | Report ]

In reply to Martin: This may be true in the theoretical sense. But as I understand it RiscPkg doesn't do anything with the previously existing system, instead it adds a new area for alternate libraries, apps and so on. Which means that both systems can co-exist.

For myself I don't think I'd really mind using an installer insead of drag/drop - I just want to know what it is doing, and I want to be reassured that anything it does can be reversed if it knackers everything up or I change my mind. The 'everything in one application directory' works well for most things. But I imagine that RiscPkg for the most part retains app dirs, just stuffing libs and shared stuff into communal areas. Presumably in the appdir there will be a file which lists everything the app needs to function. So a registry could be maintained more as a convenience, and rebuilt from scratch if it gets munged.

Someone said there are several ways being considered of letting people move apps around. The way I'm imagining is that the actual apps be stored in a fixed place, and pointer !app directories be creatable. These would really only need a !Run and a !help, both pointers, everything else could be held in the fixed path.

 is a RISC OS UserLoris on 24/02/05 2:01PM
[ Reply | Permalink | Report ]

My main concern was not, existing applications might become less self-contained, but that over time having a package management system available might tempt developers to save themselves the effort of making new/ported applications largely self-contained, maybe even abandoning the idea of application directories alltogether at some point.

 is a RISC OS UserJGZimmerle on 24/02/05 3:50PM
[ Reply | Permalink | Report ]

There is a serious need for ported applications to become _not_ entirely self-contained. This is mostly because of the requirement to use a proper shared library system, but there are other shared resources too. !SDLSound is one such example. Many ported applications don't have application directories anyway - these are typically command line tools.

Having said that, having a proper porting system (i.e. what I've just contributed to GCCSDK) makes wrapping things up in application directories, as well as adding proper packaging much easier, as it avoids most of the manual effort.

 is a RISC OS Usermrchocky on 24/02/05 4:38PM
[ Reply | Permalink | Report ]

In reply to JGZimmerle:

Actually, I've been making a point of keeping files together in application directories, avoiding use of the !System, Library and Resources directories.

Being self-contained is an entirely different matter, and my goal is to normalise as much as possible. (By 'normalise' I mean avoid redundancy, as in a relational database.) Once dependencies are managed there is little benefit in having self-contained packages and quite a few disadvantages (not just disc space, but also the risk of clashes at run-time when different applications contain different versions of a module or other resource).

 is a RISC OS Usergdshaw on 25/02/05 6:59PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • Greeks bearing gifts and email
    An introduction to the history and future of Hermes
     61 comments, latest by Stewy on 10/02/05 12:10AM. Published: 27 Jan 2005

  • Random article

  • Wakefield 2005 theatre details
    Companies going on the record
     10 comments, latest by sascott on 4/5/05 3:04AM. Published: 28 Apr 2005

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Don't expect Chris to acknowledge where Drobe's articles originally came from"
    Page generated in 0.4817 seconds.