gmane.comp.package-management.riscpkg

Re: Alternative Package manager - feedback required

alan buckley — 2009-11-23T13:26:23


Does this happen every time?
 
Can you send to me the !Boot.Resources.!Packages.Available file
from your Iyonix (in a zip file)? I will then copy it over my
version and see if I get the same thing.
 
Regards,
Alan       
_________________________________________________________________
Got more than one Hotmail account? Save time by linking them together
 http://clk.atdmt.com/UKM/go/186394591/direct/01/

reply to option for group?

Jess Hampshire — 2009-11-23T11:24:34

Hi

Is it possible to set messages from the group to have a reply to the 
group option?

I recently used googlemail to reply to Alan Buckley's post about the 
new front end he is working on, and it all went directly to him, and 
other group members might have been interested.

Thanks

Re: Alternative Package manager - feedback required

Jess Hampshire — 2009-11-23T11:08:38

In message <BLU146-W3550DBBC70CEF833EFE075F0A90-MsuGFMq8XAE< at >public.gmane.org>
          alan buckley <alan_baa-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org> wrote:


The filter behaves oddly.

I just loaded it and every other category was blank, then I maximised 
and minimised the window and it worked as expected after. (Iyonix)

Alternative Package manager - feedback required

alan buckley — 2009-11-12T13:43:59

For many years I've been slowly working towards
an alternative package manager to !RiscPkg.
Having got so far, but suffered a slight lack
of enthusiasm, I thought I would make the
very early alpha version available for people
to download and comment on so I can decide if
it's worth continuing.
 
It can be downloaded from:
 
http://alanb.drobe.co.uk/packman.zip

How to use it and contact me with feedback
is in the !Help file. I'm sure people won't
mind comments on this list if you prefer.
 
It is an alpha version so it may crash and
it needs !RiscPkg to have been installed and
working or it won't be able to do anything.
 
Theoretically it shouldn't mess up your
existing packages and you should be able
to use !RiscPkg to tidy up if it crashes
during an install.
 
All comments are welcome, but I know how
everyone will want a different UI, so if
you feel it does need a radically different
UI please also let me know if you find the
one in the application sufficient for now
as I'm unlikely to do a major redesign.

Re: Idea for making RiscPkg more flexible and userfriendly

Eric Rucker — 2009-10-24T11:22:39

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 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.

Idea for making RiscPkg more flexible and user friendly

Eric Rucker — 2009-10-24T01:02:35

I was tossing this idea around, and it was suggested that I post it
here, so here goes. This might not work in all situations, either, but
for an application where there's just one app that goes into a
directory (read: most apps,) and nothing else, this would work.

Rather than have the package contain a hierarchy of directories, and
the application to be installed being in one of those directories...
have the application be the only directory at the root level of the
package ZIP file, with the RiscPkg info inside the application.

Then, the user can copy the application to the drive, in whatever
location, and run it. Upon first run, the application would invoke the
package manager, to download any necessary dependencies, and register
the app in the package database.

This could even handle moving the app, by comparing the directory it
was originally installed in, with the <Obey$Dir> on run, and if
different, notifying the package manager of the change. Deletion would
be more difficult, but probably possible