Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Eric Rucker <bhtooefr-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
Subject: Re: Idea for making RiscPkg more flexible and user friendly
Newsgroups: gmane.comp.package-management.riscpkg
Date: Saturday 24th October 2009 11:22:39 UTC (over 7 years ago)
On Sat, Oct 24, 2009 at 02:25, Graham Shaw
<[email protected]> wrote:
> Packages containing more than one application would be easy enough to
avoid
> by splitting them into multiple packages.
>
> However, you would loose a significant amount of flexibility not being
able
> to:
> - 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
of
> 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
needed
> to implement these features, but if someone wants to try then far be it
from
> 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
place
> where he wishes.
> - When first run, the stub application invokes RiscPkg to download the
real
> 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.
 
CD: 4ms