Distributing software with RiscPkg

Essential How-to for developers

Layout of our sample RiscPkg package (Download Drawfile version)

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.

Discussion

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. Sawadee 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. JGZimmerle 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. mrchocky 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). hutchies 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) arawnsley 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. adrianl 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. mrchocky 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). Walks on 23/2/05 10:16AM [ Reply | Permalink | Report ]

For anyone who wants to see previous debate on this topic, see [link] caliston2 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? adrianl 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. SimonC 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? jjvdgeer 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. mrchocky 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. mrchocky 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. JGZimmerle 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. flypig 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. mrchocky 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. flypig 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. arawnsley 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. martin 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. mrchocky 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. caliston2 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. Jaco 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. arawnsley 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. mrchocky 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 adamr 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. mrtd 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. Walks 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. mrchocky 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. mrchocky 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. caliston2 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. caliston2 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.) Loris 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. mrchocky 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. mrtd 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 adamr 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. mrchocky 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. Loris 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. JGZimmerle 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. mrchocky 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). gdshaw 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.

Login

Search this website

This week's poll

Recent developments have left me feeling... Assured ROS will appear on new hardware 55% Pleased OS desktop features are being developed 10% ROL and ROOL will eventually kiss and make up 5% App developments are critical 10% Dave Holden sleeps easy at night 19% Discuss this | Archives

Featured articles

Wakefield 2009 wrap-up, photos and video
The weekend's RISC OS event has been and gone and we've got the rest of our lives to look forward to. Here's a round-up of extra news and Drobe's show-related coverage and some photos taken from Wakefield 2009 - plus a video from the show floor.
 16 comments, latest by AW on 29/4/09 7:41PM. Published: 27 Apr 2009

RISC OS 5 pictured running on ARM Cortex-A8 kit
Picture exclusive - This grainy photograph shows a port of RISC OS 5, sourced from the RISC OS Open project, running on a Beagleboard - a device powered by a 600MHz ARM Cortex-A8 processor with a built-in graphics chip. The port, developed by Jeffrey Lee with help from Uwe Kall and ROOL staff, is seen as a major breakthrough for the shared-source project as it proves the OS can be ported to new hardware without the need for a large team of engineers.
 75 comments, latest by rjek on 30/4/09 3:15PM. Published: 25 Apr 2009

Open documents from Windows-using pals with handy online tool
It can be a pain when someone sends you a file that can only be opened on Windows, Mac OS X or Linux - but with the help of a free-to-use website and NetSurf, Paul Stewart reveals how these documents can be viewed on RISC OS.
 6 comments, latest by AW on 8/5/09 12:12AM. Published: 19 Apr 2009

Useful links