[gccsdk] Shared library status update

alan buckley alan_baa at hotmail.com
Mon Jan 28 02:25:38 PST 2008

> On Sat, 26 Jan 2008 13:13:37 Adam wrote:
> In message , Peter Naulls wrote:
>> alan buckley wrote:
>>>> On Thu, 24 Jan 2008 14:06:51 -0800 Peter Naulls wrote:
>>>> Can we please sum up in a series of bullet points exactly how it's
>>>> going to work? I admit I haven't followed this awfully closely,
>>>> but I suspect even for those who have but aren't overly familiar
>>>> with the subject, it might not be obvious. I'm after some details,
>>>> but don't get too carried away.
>>> This is what I'm proposing, but I'm don't know if it's agreed upon.
>>>>From a users perspective.
>>> 1. Download a new application !SharedMan.
>>> [snip]
> Something else which occurred to me:
>>> 3. I'm not sure where !SharedLib should
>>> go. Is it !Boot.Resources or is it somewhere
>>> in the System directory.
> Does SharedMan need to be separate to SharedLib?

I believe it was one of Martin's points.

As !SharedLib doesn't rely in anyway on !SharedMan I thought it better
if the two were kept separate. This way !SharedMan could be replaced
or not used at all.

> 4. Drop the new library onto the window presented and it will give a
> summary of it and tell you if it's already installed, needs something
> else - etc. I don't think you've said anything about the format of the
> library distributions themselves - presumably it would be similar
> (identical?)to the RiscPkg format?[1]

I've re-added this from your other reply. The format is identical to
RiscPkg. The point of my idea is to use this existing technology.

>> [snip lots of steps]
>> To be honest, I really don't like this.
> It's a shame you couldn't contribute earlier on :(
>> It's the antithesis of what packaging and automated installing is all
>> about. Yes, for development purposes and occasional manual
>> intervention, there needs to be a semi-manual install process.
>> But most of the time, I really don't care. If an application requires
>> shared libraries, then dependencies should take care of it. Any
>> manager will be downloaded and installed automatically, as will the
>> libraries themselves. Yes, display some kind of process, and yes,
>> have a way of displaying what's installed, yes. But don't make me,
>> and more important even users, who want it to "just work" perform any
>> kind of manual steps.
> I'm not quite clear about what you're suggesting. Is it anything other
> than RiscPkg? If not, Alan's scheme incorporates that already. If
> someone chooses to use RiscPkg (and the application author packages
> their app) then everything can be done from inside RiscPkg.
>> It has been precisely this point that has been a huge hindrance with
>> users installing software, even if it's "obvious" how to download and
>> unzip/drag/copy files.
> I agree we shouldn't assume things about what's "obvious" to users - but
> that's where this thread started, so hopefully we're moved forward
> already. :)

Unfortunately if the users want to manually install these libraries, I can't
see any way of making it simpler.

Personally I would want to use !RiscPkg for installation. An ideal solution
for me would be to be able to insist that the users need to use the
existing package manager. This is definately the easiest way for users
to install anything in my opinion.

This already gives the ability to drop packages on to the !RiscPkg icon
if you really want to install them manually. (I've used this for testing).

The reasons I've come down this route are:

1. I want whatever scheme that comes into place to be able to
peacefully co-exist with the Package manager.

2. It appears there is a resistance in the RISC OS community to using
a package manager.

3. The work done for the riscpkg package manager already covers all
the versioning and installation features required for installing shared
libraries, so it seems to make sense to use this as part of any
alternative solution.


Share what Santa brought you

More information about the gcc mailing list