In message <[EMAIL PROTECTED]>, alan buckley wrote: > > On Thu, 17 Jan 2008 12:53:19 Theo Mrkettos.org.uk > > On Wed, Jan 16, 2008 at 08:35:39PM +0000, Adam wrote: > > > Martin argued that this is an imperfect system which is likely to > > > result in user-error. In particular he pointed out that it leads > > > to confusion about the difference between the "master" DSO-Libs > > > and the "skeleton" DSO-Libs. > > > > > > As an alternative, he suggested that the "master" DSO-Libs should > > > be an active object which would handle the merging, invoked by the > > > !Run file of the distributed library.[1] > > > > That would seem sensible. There's a side question of whether the > > active object can upgrade its own upgrader. With my security hat on > > (and once we've got the 'RISC OS is full of holes so why bother' > > argument out the way) I'd suggest not, that the upgrader must be > > upgraded separately. If only because this stops it breaking itself > > and makes it easier to maintain.
Yes, seems sensible. > > > Alan suggested a scheme based around libPkg which would be a > > > super-set of the scheme outlined by Martin. > > > > That would be a better solution, if someone is willing to do it. It > > would mean people could use RiscPkg to manage their self-installed > > libraries, even if they didn't want it to manage their applications. > > I'm willing to at least make an attempt at creating the installer. I > would want to use C++, the Toolbox, a modified version of the > Dreamscape library and LibPkg (plus their dependencies). All of those things are outside my experience ;) > I would hope that others would be able to at least help with the > documentation and graphics and I would definately need people willing > to test it to destruction. I'd be happy to help on the first and last of those three, but graphics is definitely not my forte! > > > [1] This has shades of the old Impression document-directory > > > approach to me. How about the distributed libraries just being a > > > single file (perhaps a zip file with a different filetype) which, > > > when double-clicked, would invoke the merge tool? > > > > That might be a bit annoying for download purposes, because servers > > know to send .zip as a binary file but not for .rolib (or whatever). > > Even if they did come as binary you'd have to tweak your MIMEMap to > > associate that extension with the filetype. You could put the > > .rolib file in a zip for protection, That's how I assumed it would work. In particular I've been thinking from the angle of how to distribute your own software, which has dependencies (rather than how to distribute the libraries by themselves from risco.info or wherever). In this context, I'd expect the library file to be in the archive next to the application directory. > > but if it's a RiscPkg archive it's already zipped - does SparkFS > > cope with zipfiles within zipfiles? I've no idea, having never used SparkFS but some quick tests here using InfoZip don't reveal any problems with this. (Of course, having the file in a zip archive doesn't rule out getting the relevant mapping in users' mimemap files in the future.) > > I think you might want > > something to cope with the base case if no libraries at all were > > installed, rather than 'file type &123 not known' which you'd get if > > you double clicked the new filetype on a clean machine. Well, this scenario is basically depending on users having the central library repository already installed. I'm not sure if there's a neat way of getting round that. (I don't actually think this is too big a problem as you would hope SharedLib would quickly become as ubiquitous as the SharedUnixLibrary module - and it only has to be installed once, unlike the libraries themselves.) > > We could do a self-extracting archive, but then it gets a bit messy > > embedding executable code (eg old SEAs broke on the 26-32bit > > transition, and they're a security problem). > > > > The structure of RiscPkg zips is already defined, so how about adding > > a little dummy application inside called !InstallMe? This then does: > > IfNotThere SharedLib:... Error Need SharedLib... Run SharedLib:!Merge > > <Obey$Dir>.^ > > Can't we just provide a control panel program like sysmerge that they > just drop the package file on to install?. Do you mean as opposed to being able to double-click the library file/application/zip? If so, how would it be invoked? Assuming SharedLib would live in !Boot.Resources, I wouldn't like to see users having to open up their boot sequence and load SharedLib that way. > This could also give options to see what is currently installed and > allow removal as well. > > Mind you this doesn't actually rule out the other suggestions for > launching it. > > Personally, I'd hope that we could just make it clear what to do with > the libraries through documentation and not bother with allowing > double-click installs or having to put extra stuff in the packages. I think "double-click installs" are a valuable goal. Installing some applications on RISC OS has become too complicated as the dependencies issue has grown (as shown by regular questions on the newsgroups) and shared libraries have the potential to exacerbate the problem. I would love to use shared libraries for my applications, but don't want to burden users with complicated installation instructions. I'd like my apps to work "out of the box" (or even "in the box" ;) ). This is, after all, one of the key benefits of the "application directory" philosophy on RISC OS which still sets it apart from other OSes. > > LibPkg would have to learn how to install from already-decompressed > > package files, if it doesn't already. It'd have to cope with the > > archive being decompressed on the fly by SparkFS rather than by > > itself, but if it's not doing anything odd with the Zip format that > > should be OK. > > > > You can then ship libsomething.zip which can be installed > > automatically by RiscPkg or manually by opening the zip and clicking > > on !InstallMe. Well, this is OK, but I do like the idea of minimizing the number of objects you're faced with when you open up (as a user) your downloaded archive. In this case, in particular, there is a danger that people will extract the contents to a "temp" directory. This is a recipe for carnage since all the different downloads would have the same directory names in the root of the archive, so you could end up with exactly the situation (merge-by-directory-structure) we're trying to avoid! Adam -- Adam Richardson Carpe Diem http://www.snowstone.org.uk/riscos/ _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
