On Sat, Oct 24, 2009 at 02:25, Graham Shaw
> Packages containing more than one application would be easy enough to
> by splitting them into multiple packages.
> However, you would loose a significant amount of flexibility not being
> - split applications between multiple packages
> - have empty packages which exist solely to pull in dependencies.
> I'm not saying this couldn't be made to work, but it would really be more
> an 'application manager' than a 'package manager'.
Well, this wouldn't necessarily supplant the current package format -
many things simply wouldn't be able to use this format. However,
applications with a single application inside would be able to use it.
> The other major difficulty would be the fairly large amount of work
> to implement these features, but if someone wants to try then far be it
> me to stop them.
> What you could perhaps do in a reasonable amount of time would be:
> - Have a site for downloading 'stub' applications, which the user can
> where he wishes.
> - When first run, the stub application invokes RiscPkg to download the
> copy of the application + dependencies, which would be stored using the
> existing package file format.
> - When run subsequently, the stub invokes the real copy.
> This would have almost the same behaviour from a user POV (provided he
> didn't inquire too closely into what was going on behind the scenes) and
> would not require any incompatible changes to the package format.
The biggest thing I don't like about that is that it, like you said,
hides what's going on behind the scenes. Maybe instead have it invoke
RiscPkg to download the real application to the directory where the
stub is, and delete the stub? Still, I don't like it, because that
approach excludes users who aren't using RiscPkg for whatever reason.
Like I said, my approach won't be suitable for all situations, but it
would increase usability when it is suitable, IMO.