Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1318 > unrolled thread

Fresh packaging ideas

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-15 17:02 +0000
    Re: Fresh packaging ideas Jim Nagel <jimnewsm10d@abbeypress.co.uk> - 2012-01-16 11:39 +0000
    Re: Fresh packaging ideas wpb <w.blatchley@yahoo.com> - 2012-01-16 05:49 -0800
      Re: Fresh packaging ideas Steve Fryatt <news@stevefryatt.org.uk> - 2012-01-16 19:01 +0000
      Re: Fresh packaging ideas Chris Evans <chris@cjemicros.co.uk> - 2012-01-17 13:04 +0000
        Re: Fresh packaging ideas wpb <w.blatchley@yahoo.com> - 2012-01-17 23:01 -0800
          Re: Fresh packaging ideas cferris@freeRemoveuk.com.invalid - 2012-01-18 11:27 +0000
          Re: Fresh packaging ideas Chris Evans <chris@cjemicros.co.uk> - 2012-01-18 15:16 +0000
      Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-17 22:32 +0000
        Re: Fresh packaging ideas Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-01-18 07:37 +0000
    Re: Fresh packaging ideas News Poster <workstuff@mail.com> - 2012-01-16 11:46 -0800
    Re: Fresh packaging ideas Alan <alan_baa@hotmail.com> - 2012-01-16 14:39 -0800
      Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-17 22:23 +0000
        Re: Fresh packaging ideas Alan <alan_baa@hotmail.com> - 2012-01-18 05:04 -0800
          Re: Fresh packaging ideas Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-01-18 21:33 +0000
            Re: Fresh packaging ideas "David Holden" <SpamBin@apdl.co.uk> - 2012-01-19 08:03 +0000
              Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-19 11:46 +0000
              Re: Fresh packaging ideas Alan <alan_baa@hotmail.com> - 2012-01-19 05:45 -0800
                Re: Fresh packaging ideas News poster <news@mistymornings.net> - 2012-01-19 19:35 +0100
            Re: Fresh packaging ideas Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-01-19 08:09 +0000
              Re: Fresh packaging ideas Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-01-19 19:36 +0000
                Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-19 20:27 +0000
                  Re: Fresh packaging ideas Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-01-19 21:18 +0000
                    Re: Fresh packaging ideas Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-01-19 23:01 +0000
                      Re: Fresh packaging ideas Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-01-20 20:22 +0000
                    Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-20 09:02 +0100
                    Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-20 09:04 +0100
                  Re: Fresh packaging ideas Jess Hampshire <jesshampshire@googlemail.com> - 2012-01-23 19:43 +0000
                    Re: Fresh packaging ideas wpb <w.blatchley@yahoo.com> - 2012-01-23 21:30 -0800
                    Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-25 16:18 +0000
                      Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-25 18:15 +0100
                Re: Fresh packaging ideas Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-01-19 21:55 +0000
                  Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-19 23:02 +0000
                  Re: Fresh packaging ideas Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-01-20 19:48 +0000
                    Re: Fresh packaging ideas Matthew Phillips <spam2011m@yahoo.co.uk> - 2012-01-20 20:44 +0000
                    Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-20 21:10 +0000
                      Re: Fresh packaging ideas Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-01-21 00:51 +0000
                        Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-21 04:39 +0100
                        Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-21 15:34 +0000
                      Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-21 04:32 +0100
                      Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-21 04:44 +0100
            Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-19 13:53 +0000
              Re: Fresh packaging ideas Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-01-19 20:56 +0000
                Re: Fresh packaging ideas Chris Evans <chris@cjemicros.co.uk> - 2012-01-20 13:32 +0000
                  Re: Fresh packaging ideas Patric@invalid.com - 2012-01-20 16:16 +0100
                    Re: Fresh packaging ideas druck <news@druck.org.uk> - 2012-01-21 09:55 +0000
                      Re: Fresh packaging ideas Fred Bambrough <fred@[127.0.0.1]> - 2012-01-21 11:00 +0000
                      Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-21 19:04 +0100
                  Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-21 04:18 +0100
                  Re: Fresh packaging ideas Alan <alan_baa@hotmail.com> - 2012-01-22 07:51 -0800
                    Re: Fresh packaging ideas Frank de Bruijn <zuiderduin@hotmail.com> - 2012-01-23 08:13 +0100
                Re: Fresh packaging ideas Alan <alan_baa@hotmail.com> - 2012-01-23 05:06 -0800
                  Re: Fresh packaging ideas Martin Bazley <martin.bazley@blueyonder.co.uk> - 2012-01-23 21:32 +0000
                    Re: Fresh packaging ideas Alan <alan_baa@hotmail.com> - 2012-01-24 05:05 -0800
                    Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-25 22:41 +0000
                      Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-26 15:33 +0100
    Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-17 06:39 +0100
      Re: Fresh packaging ideas druck <news@druck.org.uk> - 2012-01-17 23:10 +0000
        Re: Fresh packaging ideas Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2012-01-18 09:26 +0100
      Re: Fresh packaging ideas Theo Markettos <theom+news@chiark.greenend.org.uk> - 2012-01-17 23:10 +0000
    Re: Fresh packaging ideas Stuart <Spambin@argonet.co.uk> - 2012-01-17 15:20 +0000
      Re: Fresh packaging ideas Gavin Wraith <gavin@wra1th.plus.com> - 2012-01-17 16:33 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#1318 — Fresh packaging ideas

Over on the 'Trying to get PackMan to install GCC' thread in csa.apps, there
have been various discussions of the perceived shortcomings of the current
RiscPkg/PackMan format for packaging RISC OS software.  In particular,
Martin Bazley's ideas in <6d047d5152.martin@blueyonder.co.uk> and following
posts.

So here's some ideas for building on the RiscPkg work, which aim to resolve
some of them, in particular make it more user and developer friendly.  I
thought I'd start a new thread to avoid them getting mixed up in that long
one.  I should caution that this is just a flight of fancy for the moment...
no developer time is committed (unless anyone feels like having a go).  But
I present the following for comments:


1. Change the packaging format so that packages consist of a zip file with
the application at the top level, and associated Readmes etc alongside. 
Packaging information is held in a separate directory, or maybe an
application.  Let's call it !PackageInstaller for the moment.  In other
words, a package is simply an author's normal software distro but with an
additional directory.

!PackageInstaller.Control is the RiscPkg Control file, but possibly with
policy major version 2.

2. Write a 'packaging wizard' with a simple drag-and-drop
interface.  The developer fills in boxes like:

Package name
Package version
Contents: Drop application and other contents here
Dependencies: Drop other package files it depends on, or enter manually
Licence: Select from a list of known licence types, or enter your own
(non-ideal)
Copyright: Drop a file with full copyright information, full licence wording
etc
Category: roughly what the program does, chosen from a limited list
Author
Program URL
Security release: should users be discouraged from using older versions due
to security problems? (see notes on rollback below)
Other fields filled in in a similar way

The tools has a 'distribute' button, which uploads the file to the packaging
server (think 'App Store', some kind of authentication required).  It also
emits a Zip file for non-packaged distribution - that Zip still contains
!PackageInstaller.  Optionally it can also upload that Zip to an
author-defined place (eg their website).

(A similar command line tool would exist so could be run as part of a
makefile.  That tool would also be cross-platform)

3. !PackageInstaller contains the packaging information, but also has some
means of indicating how to bootstrap the package manager.  For example, it
runs the package manager if available and installs the package.  If it
isn't, it shows the user where to get it (eg opens the package manager
webpage).

4. The package manager allows you to select where the application may be
installed by drag and drop.  It remembers where the application was last
installed, and if it's since moved it looks up the application's system
variable (which it found from scanning the !App.!Run file when it installed)
and says 'the following apps have moved, I think they're here, is this
right?' It only does this if the app actually needs an update (ie don't
pester for apps that are unchanged upstream)

5. The package manager's 'where shall I put this?' dialogue has an 'I don't
care' option, which puts it in a directory structure formed from the
Category fields.  It should be possible to select a specific destination for
a few apps, and then say 'just get on with it' for all the rest.  It should
not be necessary to answer a question for every app.

6. The package manager has a means to move backward and forward in time
through the versions it has downloaded (rollback if the latest version is
broken).  Need to consider security and support implications (developers
want users on latest software; sometimes developers break the latest
software)

7. Write a tool which transforms RiscPkg packages into this format (or the
package manager can also cope with RiscPkg packages by just using a
different parser).

8. Caveat: software must be capable of self-configuring.  For example, if it
needs something set up in Choices:, it must copy it into <Choices$Write>
itself on first run.  Justification: multiple users.  Alice may install
something, and Bob may use it.  They may have different Choices directories.

9. Filer plugin for the 'App !FooApp->' menu, below Help is an option of
Manage which invokes the package manager on that app (uninstall? rollback?
check for updates <this app>? check for updates <all apps>?)

10. Core repositories are distributed.  For example repo1.riscpkg.org might
be hosted by ROOL.  repo2.riscpkg.org by riscos.info.  etc.  They contain
the same software, propagated in a similar fashion to NNTP (repo1 says 'I
have FooAp v1.1', repo2 says 'let's have it, I only have v1.0' [maybe even
using NNTP]).  Old versions are retained (except in emergencies - committing
your password, copyright violation, etc).

11. There's an easy way of adding extra repos to the list via some easy way
(eg drop a URL onto a package manager icon)

[I haven't spent too long thinking about repositories, so I'm less sure of
10 and 11]

12. All the above uses the existing RiscPkg format and infrastructure as
much as possible, but with suitable adjustments (eg to Policy Manual,
libpkg, frontends) to make it more user friendly.


All of these are merely rough sketches of how things might work.  In
particular, the social side needs more thought (why do developers like
distributing things on their homepage?  How does that fit into packaging? 
How can we align the motivations so that people will actually want to use
the system?  And so on)

Let the flames commence ;-)

Theo

[toc] | [next] | [standalone]

#1324

Theo Markettos  wrote on 15 Jan:
> So here's some ideas ...

And, while at it, choose a name that can be pronounced.
Here, "Packman" is catchier than "RiscPkg".

-- 
Jim Nagel                        www.archivemag.co.uk

[toc] | [prev] | [next] | [standalone]

#1325

On Jan 15, 6:02 pm, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
>
> Let the flames commence ;-)
>
> Theo

Ha! On the contrary, I think most of these suggestions are excellent.

I've had a few thoughts on the matter, too:

1. Are you aware of !PackIt (http://alanb.drobe.co.uk/packit.htm),
which is basically the packaging wizard you describe. I've been
playing with it today. Apart from a few minor issues, it's very nice.

2. I created a packaged font today. It installs fine, but there's no
way to automatically rescan the fonts at the end of the installation
process, which is annoying. It would be great if a package-author-
specified obey file (!PostInst or the like) could be run after package
installation, to allow for things like this. It would allow an
installed app to configure itself immediately, too.

3. Personally, I'd love to see package filenames have some sort of
standardisation in terms of version numbers. I really don't like dots
and slashes in version numbers used in filenames. "RiscPkg-v1.2" or
"RiscPkg-v1/stable" etc. It causes problems, especially when backing
up those zips across different filing systems. This may just be a
personal preference, but I'd much rather that filename versions stuck
to underscores and dashes: "RiscPkg__1_2", "RiscPkg__1-stable" or
something along those lines.

4. Could the package installer not at least have a stab at installing
dependencies for the first time over the top of unmanaged
dependencies? Say the user has SharedULib installed (unmanaged), and
then tries to install some software using the package manager that
depends on it. At the moment, the installation will fail. But couldn't
the package manager attempt to identify the version number of the
existing installation (not hard for modules, trickier but in many
cases probably possible for apps), and then pop up a message something
like:

  The software you're installing depends on X. There appears to be
version Y of X already installed on your system. The packaging manager
would like to take control of this software [, upgrading it to version
Z as it goes]. Okay?
  [x] Copy the original file to a safe location first.

Or something similar.

I know that Alan is working towards !PackMan being able to install in
a user-specified place. Once that happens, I think many more people
would be happy to use a package manager. I would say the next biggest
hurdle is the problem mentioned in 4) above. That's going to put a lot
of people off unless it can be made a bit slicker, I think.

Just my 2p. Cheers,

WPB

[toc] | [prev] | [next] | [standalone]

#1326

On 16 Jan, wpb wrote in message
    <4320af72-c9e0-4c15-907f-03cbd05e1029@v14g2000yqh.googlegroups.com>:

> But couldn't the package manager attempt to identify the version number of
> the existing installation (not hard for modules, trickier but in many
> cases probably possible for apps),

Apps which follow the Castle guidelines should have their version number in
a suitable system variable (assuming it's in step with reality, of course).

IIRC, I think Rover does it via the rather hacky method of starting the
application, then navigating to the Info window and reading the appropriate
writable icon.  Apologies to Martin if I'm thinking of another piece of
software here.

One point, of course, is that the update is under the control of the new
package, so presumably there could be some guidance in there as to how to go
about finding a version number of earlier versions -- assuming a few
'standard' methods could be dreamed up.

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                             Saturday 28 April 2012
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

#1339

In article <4320af72-c9e0-4c15-907f-03cbd05e1029@v14g2000yqh.googlegroups.com>,
wpb <URL:mailto:w.blatchley@yahoo.com> wrote:
> On Jan 15, 6:02 pm, Theo Markettos <theom+n...@chiark.greenend.org.uk>
> wrote:
> >
> > Let the flames commence ;-)
> >
> > Theo

Thanks Theo for grabbing the nettle.

> 
> Ha! On the contrary, I think most of these suggestions are excellent.

Agreed
 
> I've had a few thoughts on the matter, too:

 
> 4. Could the package installer not at least have a stab at installing
> dependencies for the first time over the top of unmanaged
> dependencies? Say the user has SharedULib installed (unmanaged), and
> then tries to install some software using the package manager that
> depends on it. At the moment, the installation will fail. But couldn't
> the package manager attempt to identify the version number of the
> existing installation (not hard for modules, trickier but in many
> cases probably possible for apps), and then pop up a message something
> like:
> 
>   The software you're installing depends on X. There appears to be
> version Y of X already installed on your system. The packaging manager
> would like to take control of this software [, upgrading it to version
> Z as it goes]. Okay?
>   [x] Copy the original file to a safe location first.

Why can't it do a file compare?
Date & length then if those agrees a file contents comparison.

The only downside I can see is the speed of a file contents comparison
but a percentage hour glass could be used!

Chris Evans

-- 
CJE Micro's / 4D                'RISC OS Specialists'
Telephone: 01903 523222             Fax: 01903 523679
chris@cjemicros.co.uk     http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex,     BN11 2EN
The most beautiful thing anyone can wear, is a smile!

[toc] | [prev] | [next] | [standalone]

#1358

On Jan 17, 2:04 pm, Chris Evans <ch...@cjemicros.co.uk> wrote:
[snip how package manager can take control of previously installed
software]
> Why can't it do a file compare?
> Date & length then if those agrees a file contents comparison.
>
> The only downside I can see is the speed of a file contents comparison
> but a percentage hour glass could be used!
>
> Chris Evans

True, it could do this to tell if the version installed and the
version it would like to be installed are one and the same, and that
would be a good thing to do. It doesn't help if the user has another
version installed. The package manager can't then know which version
is newer - its or the user's. Then some form of version probing has to
come in, or a message telling the user to sort it out manually (not
great).

WPB

[toc] | [prev] | [next] | [standalone]

#1361

In message <a1788f84-acf4-4530-8707-d07bd6412d72@c20g2000vbb.googlegroups.com>
          wpb <w.blatchley@yahoo.com> wrote:

> On Jan 17, 2:04 pm, Chris Evans <ch...@cjemicros.co.uk> wrote:
> [snip how package manager can take control of previously installed
> software]
> > Why can't it do a file compare?
> > Date & length then if those agrees a file contents comparison.
> >
> > The only downside I can see is the speed of a file contents
> > comparison but a percentage hour glass could be used!
> >
> > Chris Evans
> 
> True, it could do this to tell if the version installed and the
> version it would like to be installed are one and the same, and that
> would be a good thing to do. It doesn't help if the user has another
> version installed. The package manager can't then know which version
> is newer - its or the user's. Then some form of version probing has
> to come in, or a message telling the user to sort it out manually
> (not great).
> 

What about making use of the 'header' space and provide info about the
!RunImage version number & whether ARM7 compatable ie &21 instead of
&20.

Info could be added after - for older progs.

Some way of telling RO4/6 and RO5 modules would be handy.

-- 
Colin Ferris Cornwall UK

[toc] | [prev] | [next] | [standalone]

#1366

In article <a1788f84-acf4-4530-8707-d07bd6412d72@c20g2000vbb.googlegroups.com>,
wpb <URL:mailto:w.blatchley@yahoo.com> wrote:
> On Jan 17, 2:04 pm, Chris Evans <ch...@cjemicros.co.uk> wrote:
> [snip how package manager can take control of previously installed
> software]
> > Why can't it do a file compare?
> > Date & length then if those agrees a file contents comparison.
> >
> > The only downside I can see is the speed of a file contents comparison
> > but a percentage hour glass could be used!
> >
> > Chris Evans
> 
> True, it could do this to tell if the version installed and the
> version it would like to be installed are one and the same, and that
> would be a good thing to do. It doesn't help if the user has another
> version installed. The package manager can't then know which version
> is newer - its or the user's. Then some form of version probing has to
> come in, or a message telling the user to sort it out manually (not
> great).

If it's a Module version checking shouldn't be difficult (Open file, find
version no.)

If not a module asking the user if they want to over write seems the
appropriate step (Telling the user the two file dates would be useful). The
user could then copy out the file elsewere before procceding.
Opening the containing directory would be a nice touch!


Chris Evans

-- 
CJE Micro's / 4D                'RISC OS Specialists'
Telephone: 01903 523222             Fax: 01903 523679
chris@cjemicros.co.uk     http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex,     BN11 2EN
The most beautiful thing anyone can wear, is a smile!

[toc] | [prev] | [next] | [standalone]

#1349

In comp.sys.acorn.apps wpb <w.blatchley@yahoo.com> wrote:
> I've had a few thoughts on the matter, too:
> 
> 1. Are you aware of !PackIt (http://alanb.drobe.co.uk/packit.htm),
> which is basically the packaging wizard you describe. I've been
> playing with it today. Apart from a few minor issues, it's very nice.

Ah, no I hadn't seen that.  I'll have a play.

> 2. I created a packaged font today. It installs fine, but there's no
> way to automatically rescan the fonts at the end of the installation
> process, which is annoying. It would be great if a package-author-
> specified obey file (!PostInst or the like) could be run after package
> installation, to allow for things like this. It would allow an
> installed app to configure itself immediately, too.

That's true, but there's a danger that packages will end up copying files
around randomly rather than managing them the right way.  Also I'd hope a
package manager could be run cross-platform (eg to build a fresh disc image
for a BeagleBoard), which means running random Obey files is out (unless we
have a clever portable Obey parser).

> 3. Personally, I'd love to see package filenames have some sort of
> standardisation in terms of version numbers. I really don't like dots
> and slashes in version numbers used in filenames. "RiscPkg-v1.2" or
> "RiscPkg-v1/stable" etc. It causes problems, especially when backing
> up those zips across different filing systems. This may just be a
> personal preference, but I'd much rather that filename versions stuck
> to underscores and dashes: "RiscPkg__1_2", "RiscPkg__1-stable" or
> something along those lines.

Yes, some standardisation is good.  Bit of an opposing force if this is
trying to fit into authors' existing workflows, though.

> 4. Could the package installer not at least have a stab at installing
> dependencies for the first time over the top of unmanaged
> dependencies? Say the user has SharedULib installed (unmanaged), and
> then tries to install some software using the package manager that
> depends on it. At the moment, the installation will fail. But couldn't
> the package manager attempt to identify the version number of the
> existing installation (not hard for modules, trickier but in many
> cases probably possible for apps), and then pop up a message something
> like:
>   The software you're installing depends on X. There appears to be
> version Y of X already installed on your system. The packaging manager
> would like to take control of this software [, upgrading it to version
> Z as it goes]. Okay?
>   [x] Copy the original file to a safe location first.

Something like this would be good, though it would need to be thought out
carefully.  I think it's definitely needed though.  Maybe it's only an issue
for modules, since they're the only things that live in particular places. 
Just install the maintained version of apps, and let them coexist with older
non-maintained apps?  It's unlikely you're going to have an unmaintained app
in exactly the same (default) place?

Theo

[toc] | [prev] | [next] | [standalone]

#1359

In message <fUj*e3xXt@news.chiark.greenend.org.uk>
 on 17 Jan 2012 Theo Markettos  wrote:

> > 2. I created a packaged font today. It installs fine, but there's no way
> > to automatically rescan the fonts at the end of the installation process,
> > which is annoying. It would be great if a package-author- specified obey
> > file (!PostInst or the like) could be run after package installation, to
> > allow for things like this. It would allow an installed app to configure
> > itself immediately, too.
> 
> That's true, but there's a danger that packages will end up copying files
> around randomly rather than managing them the right way.  Also I'd hope a
> package manager could be run cross-platform (eg to build a fresh disc image
> for a BeagleBoard), which means running random Obey files is out (unless we
> have a clever portable Obey parser).

Martin Bazley has made a suggestion on the ROOL forums that BootMerge and
SysMerge be merged, and he explicitly mentions packaging as a motivation:

http://www.riscosopen.org/forum/forums/2/topics/869?page=1

It strikes me that the various operations inside !Boot currently supported by
teh Configure system all need to have command-line equivalents which the
package manager can use.  This would include the font rescanning performed by
the normal font installer.

For modules this could also cover the fact that the modules might be there
already in unmanaged form.  If installing SharedUnixLibrary via the package
manager just downloaded it somewhere and merged System, it would not have to
worry about what was there already.  That would work rather better, I think.

> > 4. Could the package installer not at least have a stab at installing
> > dependencies for the first time over the top of unmanaged dependencies?
>
> Something like this would be good, though it would need to be thought out
> carefully.  I think it's definitely needed though.  Maybe it's only an
> issue for modules, since they're the only things that live in particular
> places.

Apart from Fonts, things in !Boot.Resources, etc.!

Other unrelated suggestions that I meant to mention:

If it doesn't do it already, can the package system be enhanced to cope with
the fact that some software won't work on ARMv7 processors?  That is, there
needs to be intelligence about what software is offered and what version is
downloaded.  We may see in the future versions specially compiled to take
advantage of the Beagleboard's floating point capabilities, or its DSP unit,
so it's got to be more sophisticated than just saying "this works on
everything up to ARMv6".  Apologies if this is already covered.

Another useful thing, apart from the ability to select several packages at
once in PackMan, would be to allow the user to decide whether to add the
application to Apps, Run it or Boot it on booting, so again, this would
replicate the current Configure boot options.

I had a go at installing GCC via PackMan last night, and, aside from having
to move my existing SharedULib out of the way, it worked very nicely.  I
think PackMan is well worth building on.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#1327

On Jan 15, 6:02 pm, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
> Over on the 'Trying to get PackMan to install GCC' thread in csa.apps, there
> have been various discussions of the perceived shortcomings of the current
> RiscPkg/PackMan format for packaging RISC OS software.  In particular,
> Martin Bazley's ideas in <6d047d5152.mar...@blueyonder.co.uk> and following
> posts.
>
> So here's some ideas for building on the RiscPkg work, which aim to resolve
> some of them, in particular make it more user and developer friendly.  I
> thought I'd start a new thread to avoid them getting mixed up in that long
> one.  I should caution that this is just a flight of fancy for the moment...
> no developer time is committed (unless anyone feels like having a go).  But
> I present the following for comments:

Thanks for taking the initiative.
>
> 1. Change the packaging format so that packages consist of a zip file with
> the application at the top level, and associated Readmes etc alongside.
> Packaging information is held in a separate directory, or maybe an
> application.  Let's call it !PackageInstaller for the moment.  In other
> words, a package is simply an author's normal software distro but with an
> additional directory.
>
I still don't see the need to change the established format for the
package program itself. The current RiskPkg format seems to have
established itself to a degree so why change it? Does having
everything at the top level make the package format more RISC OS like?

A package creator means that developers packaging applications
don't need to know about the package format and the package
manager means users don't need to know about the package format when
installing software via the package manager.

The only people who might benefit from a change in package format,
are those who download the packages without using a package
manager and install the programs manually from the zip. Personally
 I've never found the package format to be especially irritating when
 installing programs in this way.

Cheers
Stan

[toc] | [prev] | [next] | [standalone]

#1330

On Jan 15, 5:02 pm, Theo Markettos <theom+n...@chiark.greenend.org.uk>
wrote:
> Over on the 'Trying to get PackMan to install GCC' thread in csa.apps, there
> have been various discussions of the perceived shortcomings of the current
> RiscPkg/PackMan format for packaging RISC OS software.  In particular,
> Martin Bazley's ideas in <6d047d5152.mar...@blueyonder.co.uk> and following
> posts.
>
> So here's some ideas for building on the RiscPkg work, which aim to resolve
> some of them, in particular make it more user and developer friendly.  I
> thought I'd start a new thread to avoid them getting mixed up in that long
> one.  I should caution that this is just a flight of fancy for the moment...
> no developer time is committed (unless anyone feels like having a go).  But
> I present the following for comments:
>
[snip for now - I may come back to these later - if you don't mind]
>
> Let the flames commence ;-)
>
I hope you don't get too many flames and people are a bit more
polite about the effort you are putting in here than they have been
towards other people elsewhere.

As I'm the author of PackMan which works on top of the current
system I don't want to keep on making comments here if you believe
it's counter-productive. So let me know if you would prefer I don't
try to make any contribution here.

Basically the bottom line is I would like to see a successful
packaging system on RISC OS. If your ideas turn out to come
to fruition as a superior and/or successful packaging system I
will quite happily switch to it myself. And would even help move
packages from the old system to the new.

You know I have a strong belief in the current system and
that it can be be improved to a point where it would be
accepted by many more people. This doesn't stop me
wishing you luck and hoping you end up producing
something fantastic.

From the top of my head the basic things I'd like to
see in a package manager is to be presented with
a list with summaries of packages. Hopefully some
sort of category/tag system so I can filter the list
and the ability to search the lists. I'd also like to
be able to see a full description and other details
as well. I believe it is extremely important for future
users of the software to have a proper copyright
file spelling out what can and can't be done with
a package.
When it comes to installing it just has to be
relatively simple and be able to install any
dependencies without me having to do anything.
There are a few other little things, but if they were
missing it wouldn't stop me using the system.

We have seen over the years many attempts to get
things happening on various aspect of RISC OS and
a lot of discussion on newsgroups about what should
be done and how things should work. It rarely seems to
turn into concrete action though or ends up withering
away due to lack of interest. I'm hoping you have
the will to see this through and end up producing
something apart from a lot of comment on the
newsgroups.

I'm also hoping this won't completely stall any
chance of packaging on RISC OS.

I will continue to develop PackMan alongside
your efforts in case they come to nothing or
you some how, despite your intentions, come
up with something worse. I hope people
will continue to try PackMan and not just wait in
case something better comes along.

If nothing else it seems to have helped crystalise
some peoples ideas of what a packaging system
should or shouldn't do.

Regards,
Alan

[toc] | [prev] | [next] | [standalone]

#1348

In comp.sys.acorn.apps Alan <alan_baa@hotmail.com> wrote:
> As I'm the author of PackMan which works on top of the current
> system I don't want to keep on making comments here if you believe
> it's counter-productive. So let me know if you would prefer I don't
> try to make any contribution here.
> 
> Basically the bottom line is I would like to see a successful
> packaging system on RISC OS. If your ideas turn out to come
> to fruition as a superior and/or successful packaging system I
> will quite happily switch to it myself. And would even help move
> packages from the old system to the new.

Hi Alan,

I should stress that I don't want to fork PackMan, or belittle your work. 
Most of the things I've mentioned are intended to be things that can build
on existing infrastructure (notably libpkg and the two 'clients' that we
have) - they're mostly ideas for the user interface rather than changes to
the core.  If they can be done by improving PackMan, so much the better.

So your comments are especially welcome, and I hope this discussion doesn't
trample on your toes.  It was mainly a way to get past the 'we don't like a
fixed disc format' point which, it seems, many users bring up as a stumbling
block.  And also thinking about how packaging could be made more user
friendly.

> You know I have a strong belief in the current system and
> that it can be be improved to a point where it would be
> accepted by many more people. This doesn't stop me
> wishing you luck and hoping you end up producing
> something fantastic.

I have a strong belief in the current system too - by the looks of it,
libpkg is a nicely written piece of code, and the system (policy manual etc
etc) has been well designed.  The main issue is insulating users (and
software developers, for they are users too) from technicalities which they
don't need to know about, and making it work with them, not against them.

> From the top of my head the basic things I'd like to
> see in a package manager is to be presented with
> a list with summaries of packages. Hopefully some
> sort of category/tag system so I can filter the list
> and the ability to search the lists. I'd also like to
> be able to see a full description and other details
> as well. I believe it is extremely important for future
> users of the software to have a proper copyright
> file spelling out what can and can't be done with
> a package.

Absolutely.  I think some kind of search is really important, and your point
about categories is good in that it's a way of finding software for the
first time, not just a place to install them.  It must be remembered that
users may not know what an app is called.

I agree with you on the copyright point too... but ideally I'd also want
that information encoded somehow so it's easy to make mechanical decisions
(can I put this on a CD to sell?) rather than reading hundreds of copyright
files.

> When it comes to installing it just has to be
> relatively simple and be able to install any
> dependencies without me having to do anything.
> There are a few other little things, but if they were
> missing it wouldn't stop me using the system.

Yes.  I think the stumbling block of not coping with existing files is the
other major thing that needs fixing...  it may be fine installing a virgin
system, but our current constituency generally aren't starting with virgin
systems.  It's a necessary evil to stimulate user acceptance.

> We have seen over the years many attempts to get
> things happening on various aspect of RISC OS and
> a lot of discussion on newsgroups about what should
> be done and how things should work. It rarely seems to
> turn into concrete action though or ends up withering
> away due to lack of interest. I'm hoping you have
> the will to see this through and end up producing
> something apart from a lot of comment on the
> newsgroups.

I know, and I'm guilty of it as much as everyone else :( [I did very
carefully say no developer time is committed] At the very least I'm hoping
to generate a bit of enthusiasm...  rather than 'packaging is not for me',
users and developers saying 'packaging is an exciting prospect if we just
fixed these few things...  I might get stuck in' which is one way of moving
things forward in a positive way...

You don't seem to mention it anywhere in the documentation, so I hope you
don't mind me pointing out that PackMan and PackIt sources are in the
riscpkg SVN repository:
http://source.riscpkg.org/
if anyone wants to play with them.

Theo

[toc] | [prev] | [next] | [standalone]

#1364

On Jan 17, 10:23 pm, Theo Markettos <theom
+n...@chiark.greenend.org.uk> wrote:
> In comp.sys.acorn.apps Alan <alan_...@hotmail.com> wrote:
>
> > As I'm the author of PackMan which works on top of the current
> > system I don't want to keep on making comments here if you believe
> > it's counter-productive. So let me know if you would prefer I don't
> > try to make any contribution here.
>
> > Basically the bottom line is I would like to see a successful
> > packaging system on RISC OS. If your ideas turn out to come
> > to fruition as a superior and/or successful packaging system I
> > will quite happily switch to it myself. And would even help move
> > packages from the old system to the new.
>
> Hi Alan,
>
> I should stress that I don't want to fork PackMan, or belittle your work.
> Most of the things I've mentioned are intended to be things that can build
> on existing infrastructure (notably libpkg and the two 'clients' that we
> have) - they're mostly ideas for the user interface rather than changes to
> the core.  If they can be done by improving PackMan, so much the better.

Theo, thanks for this reassurance. I believe we both want the best
packaging system we can for RISC OS. To that end, if you need
to fork PackMan or produce a third, better front-end or even
start from scratch, I won't mind.

If it goes the way of a fork, it's not essential, but I'd love
to see the changes so I can see if they fit into my
version of PackMan.

Also, although I like the repository idea for
packages I would love to hear Martin Bazley's
and others ideas on a different way to
distribute packages, even if it means that
PackMan isn't appropriate at all.

Talking of which, I seem to remember when
looking at ROX-Desktop on linux that is had
some kind of zero install idea for software.
Does anyone know if that may have some
useful ideas?

>
> So your comments are especially welcome, and I hope this discussion doesn't
> trample on your toes.  It was mainly a way to get past the 'we don't like a
> fixed disc format' point which, it seems, many users bring up as a stumbling
> block.  And also thinking about how packaging could be made more user
> friendly.

I think this is a very good initiative. Anything it does to provide or
improve packaging on RISC OS is most welcome.


>
> > You know I have a strong belief in the current system and
> > that it can be be improved to a point where it would be
> > accepted by many more people. This doesn't stop me
> > wishing you luck and hoping you end up producing
> > something fantastic.
>
> I have a strong belief in the current system too - by the looks of it,
> libpkg is a nicely written piece of code, and the system (policy manual etc
> etc) has been well designed.  The main issue is insulating users (and
> software developers, for they are users too) from technicalities which they
> don't need to know about, and making it work with them, not against them.

Agreed.

[snip]
>
> > When it comes to installing it just has to be
> > relatively simple and be able to install any
> > dependencies without me having to do anything.
> > There are a few other little things, but if they were
> > missing it wouldn't stop me using the system.
>
> Yes.  I think the stumbling block of not coping with existing files is the
> other major thing that needs fixing...  it may be fine installing a virgin
> system, but our current constituency generally aren't starting with virgin
> systems.  It's a necessary evil to stimulate user acceptance.

I agree. This is one of these things why constructive user feedback
is so good. I would have liked the packaging system to be able
to replace an existing file with a packaged one with little user
intervention, but it seemed to me to be a nicety that could
wait until later. I thought the current system where it at least
tells you what's in the way, but needs manual external
steps to fix it would be sufficient for now.


>
> > We have seen over the years many attempts to get
> > things happening on various aspect of RISC OS and
> > a lot of discussion on newsgroups about what should
> > be done and how things should work. It rarely seems to
> > turn into concrete action though or ends up withering
> > away due to lack of interest. I'm hoping you have
> > the will to see this through and end up producing
> > something apart from a lot of comment on the
> > newsgroups.
>
> I know, and I'm guilty of it as much as everyone else :( [I did very
> carefully say no developer time is committed] At the very least I'm hoping
> to generate a bit of enthusiasm...  rather than 'packaging is not for me',
> users and developers saying 'packaging is an exciting prospect if we just
> fixed these few things...  I might get stuck in' which is one way of moving
> things forward in a positive way...

I hope you succeed in this.

>
> You don't seem to mention it anywhere in the documentation, so I hope you
> don't mind me pointing out that PackMan and PackIt sources are in the
> riscpkg SVN repository:http://source.riscpkg.org/
> if anyone wants to play with them.
>

No, I don't mind at all. They and the libraries they use are all
open source and anyone is welcome to look at them and
play with them. They also have a copyright file so you
know exactly what the conditions are for taking them
to do your own thing. I have used standard copyrights
like the GPL for the main programs and an even less
restrictive licence for the TBX library I wrote and
use with them.

Regards,
Alan

[toc] | [prev] | [next] | [standalone]

#1367

The following bytes were arranged on 18 Jan 2012 by Alan :

> On Jan 17, 10:23 pm, Theo Markettos <theom
> +n...@chiark.greenend.org.uk> wrote:

[snip]

> > I should stress that I don't want to fork PackMan, or belittle your work.
> > Most of the things I've mentioned are intended to be things that can build
> > on existing infrastructure (notably libpkg and the two 'clients' that we
> > have) - they're mostly ideas for the user interface rather than changes to
> > the core.  If they can be done by improving PackMan, so much the better.
>
> Theo, thanks for this reassurance. I believe we both want the best
> packaging system we can for RISC OS. To that end, if you need
> to fork PackMan or produce a third, better front-end or even
> start from scratch, I won't mind.

While I am sure it's theoretically possible to morph libpkg/PackMan into
a proper package manager for RISC OS, I believe it would be a long and
tortuous process, and we could get much better results much more quickly
by simply starting with a clean slate and, this time, taking account of
user comments *before* it's laid down in code.

Packaging should be a very important and fundamental part of RISC OS,
and that means it's imperative to take the time to get it exactly right.

My instinct is to view RiscPkg as a first pass and an experience to be
learned from, not the absolute end of the story (even in a modified
form).

> Also, although I like the repository idea for packages I would love to
> hear Martin Bazley's and others ideas on a different way to distribute
> packages, even if it means that PackMan isn't appropriate at all.

If the main problem with the currently existing RiscPkg front-ends is
the lack of a flexible disc layout, then the main problem with the
libpkg back-end, and the reason I don't think the present system is
salvagable, is its reliance on repositories.

My objections to repos are not ideological at all; they're purely
practical.  I think it would be wonderful if all RISC OS software could
be gathered together in one place, but I'm also sensible enough to
recognise that as head-in-the-clouds idealism, and that, for a variety
of reasons, it will never happen.

It's down to a combination of people issues with the running of
repositories, and people issues with the maintaining of software.  There
may be many 'stable' repos around, with no sensible way for the average
user to choose between them, born of nothing more than the personal
failings of their maintainers.  There may be software which is available
from no repo, because the author refuses (for whatever reason) to let it
out of their sight, and has it under a weird homebrew licence which
makes it theoretically free but completely undistributable except from
their own page.  Linux, with its built-in open source culture, doesn't
suffer so much from the latter, whereas RISC OS, with its much smaller
userbase, doesn't suffer so much from the former - but the net result of
both alike is to render a repo-based packaging system either useless or
worse than useless.

My extremely sketchy plan for its replacement dispenses with repos
altogether, and instead of referring to each package by its name,
uniquely identifies each one by the URL its information should be
downloaded from.  Usually, this would be hosted on an author's own page,
hence creating the minimum of friction with the present system, although
I could foresee like-minded authors pooling webspace/hosting costs to
create a pseudo-'repository' of sorts - but the important thing is that
this wouldn't be compulsory, merely neater.  This enables much more
efficient dispersal of new software releases, and cuts out the middlemen
who guard the repos.  (Naturally, as at present, a rollback feature
should be available within the manager itself.)

What I'd really love would be for the absolute minimum specification of
a valid package to match up perfectly with the currently accepted
practice of distributing manually-installed software - that is to say, a
zip file containing an application, maybe a couple of preliminary text
files, possibly some extras/helper apps/resource files, and a skeleton
!Boot structure containing anything which should go in Resources,
!System, Choices, !Fonts, etc.  (That's assuming the presence of a
universal command-line boot merge utility, something currently lacking.)
Then everyone could transition to a package manager with the minimum of
effort, albeit obviously with all the bits which make package management
worthwhile missing (and 'malformed' zip files in the strange zoo of RISC
OS software could be problematic).

I realise some probably think I'm a heretic for not forcing people to do
things the 'proper' way, with dependency resolution et al., but I prefer
to think of myself as a realist, and at least this way you're training
people to use the manager.  Hopefully, much as Aemulor eased the
transition between the 26-bit and 32-bit eras, having something which at
least works, even if it's a bit of a bodge, will ultimately be more
productive than asking everybody to take the plunge simultaneously.

Above the absolute minimum baseline (which would obviously only be used
if absolutely necessary), the question becomes one of where to put
metadata - and how to get it, in the absence of a central index file,
into the manager.  It could ship with a long list of recommended
locations, but that couldn't cover everything.  While it'd be much
easier to get developers on board if they have to vary their current
building regime as little as possible, I think some sort of short
metadata file accompanying each zip is sadly going to be necessary, for
reasons of bandwidth apart from anything else.

In the 'compatibility mode' case, the manager could fake this behaviour
by storing the filename of the zip, and the date stamp of the file on
the server at the point of the last fetch.  It could then decide whether
or not to download it again by comparing the stored date against the
current one.  (I don't know how technically feasible this is, or if
there is any kind of automated server-side distribution software which
causes the date stamp to be refreshed every 24 hours or so.)

In the normal case, the metadata file would need to cope with problems
which don't arise in a centralised repo.  One of these is that the
file's location is imminently going to change, or has just changed.  In
this case, if the installed version is still up to date, the manager
updates the relevant entry in its package database but otherwise does
nothing.  Consideration also needs to be given to outdated dependency
files elsewhere on the net - I think the best solution would be for both
the distribution and the local manager to keep a record of all obsolete
URLs (of which there should never be very many, since sites, in general,
stay put), and for the manager include them in any database lookups.

Probably the biggest problem is how to find software in the first place
- which is where a lot of my original objections to repos came from.
One idea I had would be to dedicate an entire new URI scheme (say
riscpkg://) to the purpose, so that any clicks on it can be easily
claimed (via AcornURI) by the manager, and interpreted as pointing
towards (depending on filename) either a metadata file, or a
compatibility zip file.  This would result in the file being downloaded
and its contents (or filename/datestamp) being added to the local
database, after which a dialogue box would pop up asking you if you
wanted to install the software now.  To save clicks, website maintainers
could offer a limited version of a central index, accessed and
downloaded in the same way as a metadata file, but when the manager
opens it, it finds nothing but a list of URLs of other metadata
files/zips/indexes, each of which gets interpreted in turn.  (I'm not
sure making this scanning process re-entrant is really worthwhile, but
it'd be cool.)

Of course, this local database would have to be viewable and editable
through the front-end.  Due to dependency problems introduced by making
something visible to the package manager, actually removing entries
probably isn't a good idea unless the software is not installed, but you
should be able to disable all further update checks without deleting a
package.  For emergency use, you should be able to add entries by hand.

That's all I can think of for now.  Comments welcome - and, once again,
I'd like to make it quite plain that I don't want to shoot down any idea
of packaging, but I insist on it being perfect before I let it near my
computer, and I got badly burned by the one other package system I
allowed to do this.  This, of course, comes with the caveat that nobody
can be completely satisfied, but I'd like RiscPkg Mk II to at least
manage to satisfy a majority of people - even if the overwhelming
consensus is against me.

> > So your comments are especially welcome, and I hope this discussion doesn't
> > trample on your toes.  It was mainly a way to get past the 'we don't like a
> > fixed disc format' point which, it seems, many users bring up as a stumbling
> > block.  And also thinking about how packaging could be made more user
> > friendly.
>
> I think this is a very good initiative. Anything it does to provide or
> improve packaging on RISC OS is most welcome.

I agree as well.  I really should have started a separate thread long
before this, but now pretty much everything I had to say on the matter
is buried deep in the GCC one.

A round-table community discussion was exactly what I had in mind (and I
believe I stated this in one of my previous posts) to sort out the
packaging system, so I'm glad Theo's taken the initiative.

-- 
  __<^>__   "Your pet, our passion." - Purina
 / _   _ \  "Your potential, our passion." - Microsoft, a few months later
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#1368

On 18-Jan-2012, Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:

> While I am sure it's theoretically possible to morph libpkg/PackMan into
> a proper package manager for RISC OS, I believe it would be a long and
> tortuous process, and we could get much better results much more quickly
> by simply starting with a clean slate and, this time, taking account of
> user comments *before* it's laid down in code.

> My instinct is to view RiscPkg as a first pass and an experience to be
> learned from, not the absolute end of the story (even in a modified
> form).

ISTR saying almost exactly that a very, very long time ago and you agreed
with me and then the whole thing got forgotten about in the pro/anti debate.
None of the people engaged in that seemed to understand that the ONLY reason
people were arguing against is because the current offering just don't do
what they want and, IMO, would take more work to 'fix' than starting out
from scratch.

> What I'd really love would be for the absolute minimum specification of
> a valid package to match up perfectly with the currently accepted
> practice of distributing manually-installed software - that is to say, a
> zip file containing an application, maybe a couple of preliminary text
> files, possibly some extras/helper apps/resource files, and a skeleton
> !Boot structure containing anything which should go in Resources,
> !System, Choices, !Fonts, etc.  (That's assuming the presence of a
> universal command-line boot merge utility, something currently lacking.)
> Then everyone could transition to a package manager with the minimum of
> effort, albeit obviously with all the bits which make package management
> worthwhile missing (and 'malformed' zip files in the strange zoo of RISC
> OS software could be problematic).

I agree. It would fairly simple for each zip file to contain a text file
with a commonly agreed upon name which would contain the information
required by the package manager *but* in clearly human readable (and
understandable) form so people who wanted to install manually would know
where to put stuff and whether to merge or replace, etc. This would just
require a few mutually agreed keywords.

With all due respect to the people who've already started the projects IMO
the real problem is that they're programmers and have looked at the whole
thing from that POV. What is needed is for the programmers to back off until
the 'rest of the world' has come up with some sort of idea of what they
want. After all, they are the ones who will have to use it [1] and if it
doesn't suit (no matter how 'wonderful') it will fail.

To create a successful program that will be widely used first you decide
what you want it to do, which requires 'market research'. Next you decide
how you're going to do it; you 'design' the program and, very important, the
user interface. Then, and only then, do you start writing code. For obvious
reasons most people whose expertise is in programming tend to truncate the
first two stages somewhat and then end up having to re-design and re-write a
lot of stuff, which is the state we're in now.

[1] I suppose I would have to include me in this as well. As I own and
distribute more RISC OS software titles than anyone else anything that wants
to be 'universally accepted' ideally should work with my stuff.

-- 
David Holden  -  APDL  -  <http://www.apdl.co.uk>

[toc] | [prev] | [next] | [standalone]

#1370

In comp.sys.acorn.apps David Holden <SpamBin@apdl.co.uk> wrote:
> ISTR saying almost exactly that a very, very long time ago and you agreed
> with me and then the whole thing got forgotten about in the pro/anti debate.
> None of the people engaged in that seemed to understand that the ONLY reason
> people were arguing against is because the current offering just don't do
> what they want and, IMO, would take more work to 'fix' than starting out
> from scratch.

That is the dilemma.  But, given we don't have an infinity of programmer
time (indeed it remains to be seen if there is any programmer time at all),
the question is biased because we have one codebase that exists: proponents
need to make a more convincing argument that starting from scratch is a
substantial improvement.

My point being that libpkg/PackMan is actually quite layered software. 
Don't like the repository format? Replace it with something else.  UI
annoying?  Rewrite that.  Want to cross-install packages?  Port libpkg to
Linux.  Each of these can be done independently while retaining the core
structure.  The core functions (listed in the next paragraph) are the tricky
and tedious work of writing a package manager, and they're already done.

> I agree. It would fairly simple for each zip file to contain a text file
> with a commonly agreed upon name which would contain the information
> required by the package manager *but* in clearly human readable (and
> understandable) form so people who wanted to install manually would know
> where to put stuff and whether to merge or replace, etc. This would just
> require a few mutually agreed keywords.

I think you're seeing the package manager as simply a copy tool, which is
only one of its functions.  At the moment it already also does:
1. Dependency management: does this package need 17 more installed first?
2. File tracking: it knows where every file it installed came from, and
which package it belongs to.  Otherwise when you want to delete a file how
do you know what it'll affect?
3. Consistency checking: does package A conflict with package B?
4. Update checking: is there a newer version of this package out there?

While packages can easily be built to be manually installed without being
managed, it's a substantial amount of work for the user to do all of the
above.  And it's very tedious work (pulling in data from various sources and
calculating dependency graphs).  It's not sensible to expect even the most
technical control-freak user to do all of this (except perhaps in the case
of debugging the system).  So you only get the full benefit of packaging if
you're prepared to let a tool do it for you.

Now you may argue that the above is overkill for RISC OS, and you might be
right.  But there have been a number of examples that begin to touch on the
various issues.  32 bit compatibility, ARMv7 compatibility, various
conflicting Toolbox modules out there, danger of multiple softloading BASIC
or SharedCLib modules, 26/32/26+32 Clib stubs versions.  So far we've
muddled along.  But ELF shared libraries (in GCC) mean this becomes a much
more pressing issue.

> To create a successful program that will be widely used first you decide
> what you want it to do, which requires 'market research'. Next you decide
> how you're going to do it; you 'design' the program and, very important, the
> user interface. Then, and only then, do you start writing code. For obvious
> reasons most people whose expertise is in programming tend to truncate the
> first two stages somewhat and then end up having to re-design and re-write a
> lot of stuff, which is the state we're in now.

Yes, I agree, and this is often lacking.  If we didn't have a prototype
system out there, we'd never be discussing its failings.  But it's
unfortunate that those who don't understand how the system works are
dismissing it out of hand because of UI failings when the UI is actually
easy to change.  That nobody has changed it yet to everyone's satisfaction
is just a feature of the tiny amounts of developer time we have.

Theo

[toc] | [prev] | [next] | [standalone]

#1371

On Jan 19, 8:03 am, "David Holden" <Spam...@apdl.co.uk> wrote:
> On 18-Jan-2012, Martin Bazley <martin.baz...@blueyonder.co.uk> wrote:
>
> > While I am sure it's theoretically possible to morph libpkg/PackMan into
> > a proper package manager for RISC OS, I believe it would be a long and
> > tortuous process, and we could get much better results much more quickly
> > by simply starting with a clean slate and, this time, taking account of
> > user comments *before* it's laid down in code.
> > My instinct is to view RiscPkg as a first pass and an experience to be
> > learned from, not the absolute end of the story (even in a modified
> > form).
>
> ISTR saying almost exactly that a very, very long time ago and you agreed
> with me and then the whole thing got forgotten about in the pro/anti debate.
> None of the people engaged in that seemed to understand that the ONLY reason
> people were arguing against is because the current offering just don't do
> what they want  and, IMO, would take more work to 'fix' than starting out
> from scratch.

This is the problem, it is in your opinion, and you are as entitled
to it as much as I am. Mine has always been it should be possible
to "fix" the current system (and that the underlying design is
sound - note I'm not saying perfect here),

I still welcome this thread and if the conclusion is PackMan and
LibPkg can't be built on to achieve what is required then I can
live with that.

[snip]
>
> With all due respect to the people who've already started the projects IMO
> the real problem is that they're programmers and have looked at the whole
> thing from that POV. What is needed is for the programmers to back off until
> the 'rest of the world' has come up with some sort of idea of what they
> want. After all, they are the ones who will have to use it [1] and if it
> doesn't suit (no matter how 'wonderful') it will fail.

I am a programmer and a user. I didn't invent the packaging
format or RiscPkg but used it first and decided I liked it.
That's why I built PackMan to improve the user-interface in a way
I liked and with user feedback hopefully in ways others likes.
But you are correct, the programmer isn't the person who
should have the last word on what users like. It's the users
themselves.

>
> To create a successful program that will be widely used first you decide
> what you want it to do, which requires 'market research'. Next you decide
> how you're going to do it; you 'design' the program and, very important, the
> user interface. Then, and only then, do you start writing code. For obvious
> reasons most people whose expertise is in programming tend to truncate the
> first two stages somewhat and then end up having to re-design and re-write a
> lot of stuff, which is the state we're in now.

OK, this is what should be done in the perfect world. I see no
evidence
that market research wasn't done, but maybe it missed the part
of asking in a more general and publicised forum.

In my opinion the design of the current packaging system was very
well done. One important consideration of design it to add flexibility
so it can be refined later and I believe that was done.

Again in a perfect world, a fully functioning and perfect program
would come out of the end of it, but even then I'm sure there
would be teething problems and things people don't like. At all
stages you need flexibility and be able to review and change
things.

My approach with PackMan to release a new UI with some
new features and reimplementation of old features and then
release it into the world to get feedback, while I continued
to build on it and incorporate any feedback I could. As time
is limited I believed (and still believe) this is a valid
approach.I don't believe I've ever given the impression that
it was a finished application that's fixed in stone. The
version numbering and the fact I use the word beta when
announcing new versions I was hoping would be enough
of a clue.

I will continue to develop PackMan in this way while these
discussion are happening, and make note of, and try to
incorporate some of the ideas presented as time permits.
This doesn't mean I will desperately hang on to it if
this thread comes up with a concrete proposals that
are implemented.

>
> [1] I suppose I would have to include me in this as well. As I own and
> distribute more RISC OS software titles than anyone else anything that wants
> to be 'universally accepted' ideally should work with my stuff.

It would be fantastic if your software and titles could be packaged.
I just hope you will accept the conclusion here and support them even
if they aren't exactly to your liking.

Regards,
Alan

[toc] | [prev] | [next] | [standalone]

#1373

In message <70417261-5c8a-4402-af03-a0daa664c453@v14g2000vbc.googlegroups.com>
          Alan <alan_baa@hotmail.com> wrote:

[snip]
> My approach with PackMan to release a new UI with some
> new features and reimplementation of old features and then
> release it into the world to get feedback, while I continued
> to build on it and incorporate any feedback I could. As time
> is limited I believed (and still believe) this is a valid
> approach.I don't believe I've ever given the impression that
> it was a finished application that's fixed in stone. The
> version numbering and the fact I use the word beta when
> announcing new versions I was hoping would be enough
> of a clue.
> 
> I will continue to develop PackMan in this way while these
> discussion are happening, and make note of, and try to
> incorporate some of the ideas presented as time permits.
> This doesn't mean I will desperately hang on to it if
> this thread comes up with a concrete proposals that
> are implemented.
> 
Thanks for your clarity and your commitment to the project you started.
For my very minor part, I will make a point of using PackMan as it
develops to follow its progress.

I think that there is a lot of noise here, but ultimately only one
developer who is actually doing anything. I am still inclined to
think that that may well be the best way forwards.
Cheers
 Stan

-- 
An Iyonix and a Beagleboard xM in Buskerud.

http://mistymornings.net 

[toc] | [prev] | [next] | [standalone]

#1369

In message <ba56ac5352.martin@blueyonder.co.uk>
 on 18 Jan 2012 Martin Bazley  wrote:

> My extremely sketchy plan for its replacement dispenses with repos
> altogether, and instead of referring to each package by its name,
> uniquely identifies each one by the URL its information should be
> downloaded from.  Usually, this would be hosted on an author's own page,
> hence creating the minimum of friction with the present system, although
> I could foresee like-minded authors pooling webspace/hosting costs to
> create a pseudo-'repository' of sorts - but the important thing is that
> this wouldn't be compulsory, merely neater.

I do not see how this offers any advantages over a repository system.  How I
see it is that a packaging system, to be worthwhile, must offer at least the
following:

a) a means of browsing software packages and selecting them for installation
b) a means of telling the user about updates to software that is installed
c) a means of installing other bits and pieces that the software depends on

How, in your system, does the PackMan replacement know what software is out
there and satisfy requirement (a)?  How, if someone else takes over the
software and offers updates from a new site (as has happened recently with
!PDF) does the system satisfy (b)?

As I believe was noted in other threads, it is perfectly possible with a
conventional packaging system to add multiple sources: any number of
repositories can be supported.  At the extreme you could have one
repository per author, or one repository per application.  We currently have
two repositories for RISC OS, one at riscpkg.org and one at riscos.info but
it's quite open to me, for example, to create a respository at
sinenomine.co.uk and package up my software there.  All I would have to do is
persuade the users to add my repository to their PackMan config, and it would
all work.

So authors are free to do this now.  But of course unless you have acertain
critical mass of useful stuff in your repository, no-one is going to bother
to configure that extra repository in the package manager, so I would
probably be better off creating pacakages and adding them to one of the two
existing repositories.  I would get more exposure that way.

In your suggestion, how does the user and the package installer tool know
where all these apps are?  At the least the URLs of all the application zip
files have to be listed centrally somewhere.  Is that so much easier to
create than a repository?

I see you've given more details later, with the riscpkg:// suggestion.  Does
the software developer put a riscpkg:// URL in his or her posting on
csa.announce then?  He/she would also have to put an ordinary URL for those
heretics who do not like the new-fangled way of doing things.

If we're going to do this, why not go with the existing repository idea,
and have a riscpkg:// URL simply add a new source to PackMan?  Then the
independent-minded software author can set up and maintain his/her own
repository easily, satisfying your objections to central repositories, but we
can nevertheless retain the current infrastructure, which already has
significant backing from things like the autobuilder packages on riscos.info.

With the state of RISC OS development at the moment, we should not be
throwing away what we have and starting from scratch: we need to build on
what's already there.

> What I'd really love would be for the absolute minimum specification of a
> valid package to match up perfectly with the currently accepted practice of
> distributing manually-installed software - that is to say, a zip file
> containing an application, maybe a couple of preliminary text files,
> possibly some extras/helper apps/resource files, and a skeleton !Boot
> structure containing anything which should go in Resources, !System,
> Choices, !Fonts, etc.  (That's assuming the presence of a universal
> command-line boot merge utility, something currently lacking.) Then
> everyone could transition to a package manager with the minimum of effort,
> albeit obviously with all the bits which make package management worthwhile
> missing.

I think that's the big problem with this suggestion: all the bits which make
package management worthwhile would be missing.

I think that the way forward is as Theo has outlined:

Improve PackMan and the underlying library so that:

a) the user gets the choice of where on the hard drive to install the
application

b) the manager can cope with the user then moving it (e.g. locating via
system variables if the app has been seen already, or asking the user to
locate it)

c) better handling of module installation and existing unmanaged components
by using an improved Boot Merge command line tool.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web