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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#1374

The following bytes were arranged on 19 Jan 2012 by Matthew Phillips :

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

[snip]

> > 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 you've missed my point, both here and in your objections to
abolishing repositories.

The fact is: creating and maintaining a repository is not trivial, and
the package format itself currently has an extremely high technical
barrier to entry.  I know you desperately want to force everyone to do
it 'properly' straight from the get-go, but that's not a credible
proposition except with the aid of ludicrous amounts of optimism.  If we
carry on as we are, even if the most gaping flaws in RiscPkg are patched
up, uptake will still be extremely low - and that is, quite simply,
because most applications have not been packaged, and probably never
will be.

I know I said not having the bits which make package management
worthwhile would be a big problem (although, if you read my post
properly, you'll see I suggested a way in which automatic updating could
be implemented), but you have to be realistic about this.  How long did
it take before a majority of software could be run on the Iyonix without
the aid of Aemulor?  Do you really think that takeup of packaging will
be encouraged in the least helped by instantly excluding 90% of all RISC
OS software from people who use it?

A similar principle applies to repositories.  Like it or not, a lot -
possibly a majority - of RISC OS software will never be in one.  Perhaps
that's because nobody's seen fit to package it yet, perhaps it's because
someone with write access to the repo didn't notice it, perhaps it's
because the author refuses to allow it (which some do).  Repos are a far
more practical suggestion in the Linux software scene (not that they
worked out great there either), but RISC OS's developers are far more
idiosyncratic.

And having separate people to write and package software - it's already
the case for 99% of software, and will continue to be so due to the
aforementioned reluctance among developers to learn about the complex
new system - is a complete nightmare in the making.  How long might pass
between a new release being made on comp.sys.acorn.announce and a new
package being available for those poor users of RiscPkg?  What if it's
never publicly announced at all (or only announced on a private mailing
list), but simply appears on the author's website, as is increasingly
the case?

Would you rather have mediocre package management, or no package
management at all?

When the new package format is designed, it must put simplicity first,
and the manager must be able to fill in sensible default values for,
preferably, every field.  This isn't because it'll theoretically deliver
the finest possible package solution for the RISC OS community, but
because it will, in practice, deliver any package solution at all.

Everyone: less of the wide-eyed idealism, please.  If we're too pure and
precious about the principles of packaging, then all that will happen is
you'll scare the takeup away.

-- 
  __<^>__   === RISC OS is a work of art.  Some people adore it,  ===
 / _   _ \  === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive.                                        ===
 \_>   <_/  ======================= Martin Bazley ===================

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

#1375

In comp.sys.acorn.apps Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> The fact is: creating and maintaining a repository is not trivial, and
> the package format itself currently has an extremely high technical
> barrier to entry.  I know you desperately want to force everyone to do
> it 'properly' straight from the get-go, but that's not a credible
> proposition except with the aid of ludicrous amounts of optimism.  If we
> carry on as we are, even if the most gaping flaws in RiscPkg are patched
> up, uptake will still be extremely low - and that is, quite simply,
> because most applications have not been packaged, and probably never
> will be.

I think I see where you're coming from.  We currently have software
represented by a series of isolated points (Zip archives) on isolated
servers, with minimal relationship between them (except, say, the ARMv7
compatibility list, or csa.announce postings, or random hyperlinks like the
Acorn webring).  There's no way I can find out what's out there, because I
can't travel from one point to another ('traversing the graph' in
maths-speak).

So there's two questions: one, how to make such Zip archives automatically
installable and two, how to create such connections (the 'graph')

The first is I suppose feasible, with quite a lot of heuristics, special
casing, bodges etc.  Potentially it's a one-off: the system could be
'taught' how to install the package once, and then that applies to everyone. 
But the system will get caught out if the layout changes.

The second is a case of building links between points (programs or servers). 
The topology is variable - it could be a line, a star, a mesh, anything. 
Traversing the graph means something Google-like, following every link to
see where it leads.  Potentially that crawler tool then provides us with the
whole graph it found, so that every user doesn't have to scan the internet
themselves.  Other than on a 'repository' server, I'm unclear where such
links would get stored: there's not much motivation for J. Random Author to
host links to other software (since he'll then have to keep them current).

This is actually quite a complex system, but let's put that to one side for
the moment.  Questions:

1. Extracting version information from random zipfiles is hard (except for
modules).  How do you propose this?  To a first approximation, we need to
consider desktop applications, command line utilities (Absolute,
Utility and BASIC), modules, system resources (Fonts etc).
2. How do you handle dependencies in this scheme?  (Accurate version
information is needed for dependency checking)
3. How do you handle conflicts?
4. How do you do sensible unmanned installation, without having to provide
explicit information where every app goes?

The danger with heuristics is we'll end up installing things that were never
meant to be installed - eg someone puts out a 'this may corrupt your hard
drive' version, it's too easy for it accidentally be picked up by a tool
scanning websites for likely-looking Zips to install.

My point is that this is pretty risky... there are plenty of ways it can go
wrong.  While it shifts the load from application developers to the package
manager author, it multiples the work for them by (guestimates number) a
factor of 3-5.

If authors help out in structuring their archives, it de-risks it quite a
lot.  But that throws out a primary motivation (zero work for authors) and
we're back to the question of repositories (unified or distributed).

Theo

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

#1377

The following bytes were arranged on 19 Jan 2012 by Theo Markettos :

[snip]

> I think I see where you're coming from.  We currently have software
> represented by a series of isolated points (Zip archives) on isolated
> servers, with minimal relationship between them (except, say, the ARMv7
> compatibility list, or csa.announce postings, or random hyperlinks like the
> Acorn webring).  There's no way I can find out what's out there, because I
> can't travel from one point to another ('traversing the graph' in
> maths-speak).

I don't see why you'd want to.  I don't think package managers should
consider one of their primary purposes to be to aid the discovery of
software - that way lies control-freakery of the kind I've already seen
too much of.  Google will suffice.

> So there's two questions: one, how to make such Zip archives automatically
> installable

Your average software zip file contains an application directory,
possibly some boot components in skeleton directory structures with
defined names, and possibly some installation instructions.  Installing
that, except in the really kooky cases, is trivial even for a computer.

> The first is I suppose feasible, with quite a lot of heuristics, special
> casing, bodges etc.  Potentially it's a one-off: the system could be
> 'taught' how to install the package once, and then that applies to everyone.
> But the system will get caught out if the layout changes.

I sincerely hope no such thing gets implemented.  If the manager does
get tripped up, the best that can be done is to install the package
manually, just like previously.

(Probably the manager should offer a preview of what it's going to do,
and offer you the chance to decline and either give up or complete the
process by hand.)

> The second is a case of building links between points (programs or servers).
> The topology is variable - it could be a line, a star, a mesh, anything.
> Traversing the graph means something Google-like, following every link to
> see where it leads.  Potentially that crawler tool then provides us with the
> whole graph it found, so that every user doesn't have to scan the internet
> themselves.  Other than on a 'repository' server, I'm unclear where such
> links would get stored: there's not much motivation for J. Random Author to
> host links to other software (since he'll then have to keep them current).

No such links would exist, and the only 'repository' would be on the end
user's hard disc.  Obviously some useful links to software should be
supplied by default, but I don't think the main problem with installing
RISC OS software is an inability to find it in the first place.
(Centralised repos, on the other hand, make it *much* harder to find the
package you want than simply Googling for the author's home page,
particularly if it turns out you have to install an entire new repo.)

> This is actually quite a complex system, but let's put that to one side for
> the moment.  Questions:
>
> 1. Extracting version information from random zipfiles is hard (except for
> modules).  How do you propose this?  To a first approximation, we need to
> consider desktop applications, command line utilities (Absolute,
> Utility and BASIC), modules, system resources (Fonts etc).

Take the date stamp from the server and like it.  Anything else would
entail pointlessly downloading the file at random intervals.  Yes, this
is vulnerable to server-side cock-ups, random refreshes, etc., but the
worst that can happen is a bit of wasted bandwidth - which would have
been wasted anyway if you kept downloading that same zip to peek inside
its obey files.

> 2. How do you handle dependencies in this scheme?  (Accurate version
> information is needed for dependency checking)

You don't.  This is a 'bare bones' solution, to be encouraged only as a
transitional measure until packages become the norm, not the exception.

People didn't hold off 32-bitting their software just because Aemulor
was available, but you can bet people would have held off buying an
Iyonix if it wasn't.  (The lack of a similar solution for ARMv7 is still
making a lot of old-school users reluctant to buy an ARMini.)

> 3. How do you handle conflicts?

You don't.

> 4. How do you do sensible unmanned installation, without having to provide
> explicit information where every app goes?

I thought not being able to provide explicit information was one of
people's main beefs with RiscPkg?

I didn't propose the 'minimum baseline' bodge as a complete packaging
solution, only as something to sweeten the medicine and smooth the
transition.  My preference for a fully-fledged solution would be rather
more sophisticated (fleshed out slightly in my other post), but we do
need to keep the minimum-effort option open, because you've seen what
happens when we don't.

-- 
  __<^>__
 / _   _ \         You always find something in the last place you look.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

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

#1379

In message <4cc92e5452.martin@blueyonder.co.uk>
 on 19 Jan 2012 Martin Bazley  wrote:

> > 2. How do you handle dependencies in this scheme?  (Accurate version
> > information is needed for dependency checking)
> 
> You don't.  This is a 'bare bones' solution, to be encouraged only as a
> transitional measure until packages become the norm, not the exception.

But how then do you encourage uptake of a better system later which can cope
with dependencies?  Or have I misunderstood you?  Once packages of your
design have become the norm, what is the next step, if any?

We need something to manage dependencies, as shared libraries are likely to
become more prevalent.  The present aid for finding and installing these is a
proper packaging solution which handles dependencies.

> > 4. How do you do sensible unmanned installation, without having to
> > provide explicit information where every app goes?
> 
> I thought not being able to provide explicit information was one of
> people's main beefs with RiscPkg?
> 
> I didn't propose the 'minimum baseline' bodge as a complete packaging
> solution, only as something to sweeten the medicine and smooth the
> transition.  My preference for a fully-fledged solution would be rather
> more sophisticated (fleshed out slightly in my other post).

Could you explain what the fully-fledged solution would look like, then? 
There's no point adopting the minimum baseline if it's not ultimately a step
in the right direction.

Unmanned installation is important, and the main motivator behind this work. 
We are wanting an elegant solution which makes it easy for new RISC OS users,
or RISC OS users with new machines, to find and install lots of software.

I know what a hassle it is finding all these bits of software one by one to
install on a new Beagleboard, even with Google.  You have to trawl through
your other RISC OS machine finding the apps you haven't installed yet, copy
them across to the Beagleboard, run them, find they don't work because of
something missing from !System.  Find the thing in !System.  Find it doesn't
function on ARMv7.  Search for the thing on the web and download a patch or a
new version.  Repeat from step 1 for next piece of software.  Plus go and
update the ROOL Wiki if you feel like it and have a suitable browser.

How much easier to just select those packages and let PackMan do the hard
work.  Quite a few folk have bought new hardware recently, so there's a much
better appreciation of the benefits of packaging.  (I realise you have a new
machine too, but perhaps your experience is different.)

We can capitalise on this awareness, both with developers and users.  But we
have to have a solution which can make discovery and automatic installation
easy.

If we go with your proposal, can the metadata file (whether stored inside the
zip file or alongside it at foo.txt) not list the riskpkg:// URLs for the
dependencies?  That would at least go a bit further towards the ideal.  In
fact, I thought that that was part of your proposals, but must have misread
what you wrote elsewhere.  If your scheme doesn't aid discovery, and doesn't
handle dependencies then all it is is a nice way of clicking to install and
of checking for updates at the same location.

And a way of distributing riskpkg:// URLs in bulk to feed into the installer
would be useful: why not allow references to further sources inside the
metadata files?

The advantage of your proposals is that we can have an installer which can
fetch and install apps from existing zip files.  Can we combine that somehow
with the fuller solution others are backing?  There's got to be some middle
ground here.

-- 
Matthew Phillips
Durham

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

#1387

The following bytes were arranged on 19 Jan 2012 by Matthew Phillips :

> In message <4cc92e5452.martin@blueyonder.co.uk>
>  on 19 Jan 2012 Martin Bazley  wrote:
>
> > > 2. How do you handle dependencies in this scheme?  (Accurate version
> > > information is needed for dependency checking)
> >
> > You don't.  This is a 'bare bones' solution, to be encouraged only as a
> > transitional measure until packages become the norm, not the exception.
>
> But how then do you encourage uptake of a better system later which can cope
> with dependencies?  Or have I misunderstood you?  Once packages of your
> design have become the norm, what is the next step, if any?

Yes, you've pretty epically misunderstood me.  This is *not* my proposed
packaging system, for obvious reasons.  I've detailed the next step -
involving metadata, riscpkg:// dependencies, and a default 'getting
started' software list (and easy way to add more URLs in bulk)
elsewhere.

> If we go with your proposal, can the metadata file (whether stored inside the
> zip file or alongside it at foo.txt) not list the riskpkg:// URLs for the
> dependencies?  That would at least go a bit further towards the ideal.  In
> fact, I thought that that was part of your proposals, but must have misread
> what you wrote elsewhere.

No, you've misread what I wrote here.  That's exactly what I was
proposing.

> And a way of distributing riskpkg:// URLs in bulk to feed into the installer
> would be useful: why not allow references to further sources inside the
> metadata files?

My thoughts entirely.  You've evidently missed a post somewhere.

-- 
  __<^>__
 / _   _ \           It is written that Geeks shall inherit the Earth.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

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

#1381

On Thu, 19 Jan 2012 21:18:26 GMT, Martin Bazley 
<martin.bazley@blueyonder.co.uk> wrote:

> only as something to sweeten the medicine and smooth the transition.

Transition? From what to what? Is this the Protestant Work Ethic? So 
as not to frighten anybody, we'll adapt little by little and do the 
same things over and over with small alterations each time...

As opposed to, you know, doing it right in the first place.

Have you used a package manager on Linux? Do you know what it 
actually does *beyond* "installs stuff"? It is, certainly, a rather 
alien concept to traditional RISC OS, however as more things get 
ported between systems, there may be increasing need for package 
management.


Best wishes,

Rick.

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

#1382

On Thu, 19 Jan 2012 21:18:26 GMT, Martin Bazley 
<martin.bazley@blueyonder.co.uk> wrote:

> Google will suffice.

Oh.
My.
God.

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

#1405

In message <hUj*W8HXt@news.chiark.greenend.org.uk>
          Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:

>> because most applications have not been packaged, and probably never
>> will be.

> I think I see where you're coming from.  We currently have software
> represented by a series of isolated points (Zip archives) on isolated
> servers

<snip 2nd question>

> how to make such Zip archives automatically installable

It seems to me that this should be approached in two ways.

There should be the fall back option, where the packager presents a 
list of packages which it will fetch for the user to install manually. 
This would not need to involve the main underlying package mechanism. 
This would just be a convenience feature, to help find software.

The vast majority of items that would fall into this category would be 
26 bit programs, and they would be far less likely to be of interest 
to a new Pi or BB user (i.e. of interest users who would be used to 
having to find the software and then install it by hand).

The other method would use a (manually created) packaging file that 
contains the location of the archive and a mapping between the 
locations of the contents and where they would be on a proper package.

The mapping file would be in the riscpkg folder of the package, and 
the archive would either also be in it, or at another location.

The main advantage would be to allow proper (from the user 
pesrpective) packaging when dependencies don't have the correct 
licence to be packaged normally.

There should also be a way of taking possesion of non managed items 
once a managed version becomes available. There shouldn't be any 
problems with modules, because they merge manually happily enough.

Applications should be treated as version zero and backed up, if it 
exists in the install location.

I do feel the front end should be presented as an App store and there 
should be no fork (or duplication) of the underlying packaging 
mechanism. (Other than as above for fetching completely non packaged 
item).

I would also like the front end to be a filesystem i.e. folders in 
Resources:$ representing:

the configured repositories, (help would get the information, and 
opening would download apps that aren't installed, dragging would 
install to the chosen location, refresh would update from that 
repository)

installed apps (as stubs like in Apps, but in folders matching the 
category)

actual files (the apps could be copied to create a non managed copy, 
or moved so that they are located elsewhere).

There would need to be a configure entry (and a stub to open it) for 
updating.

-- 
Jess Hampshire

Plain text emails with interleaved, trimmed replies please. (RFC 1855)

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

#1408

Personally, I think that until someone comes along and says they're
willing to commit a considerable amount of time to some new packaging
system (back- and front-ends), the realism Martin called for above
lies in accepting that we do have a starting point already, and it's
not at all bad. Really, I think !PackMan is coming along very nicely.
Huge thanks to Alan for that. (And may I say your pragmatic and open
approach to this whole discussion is a real credit it to you...)

For me, the main point about !PackMan is that it's being actively
developed, and not only that, it's based on a modern C++ Wimp/Toolbox
library, which is also being actively developed. Alan's already says
he intends to allow users to install packages to chosen locations
rather than the set ones in a future version. If the other major issue
of how to handle dependencies that are already installed but not (yet)
under management could also be addressed (by anyone; !PackMan is open-
source - another thing in its favour), then in my opinion we'd have a
pretty good implementation already.

I can't really comment on just how complicated or otherwise the
internals of riscpkg are (Martin called for greater simplicity above),
but with the arrival of !PackIt, creating packages is very easy in my
experience.

It seems like your main gripe with the current system, Martin, is that
it leaves the vast majority of old, now unmaintained software out in
the cold. Is that right? Rather than replacing the whole current
packaging system, could we not have an extension to it that allows for
plain zipfile packages sans metadata, installed either automatically
to a set location ("$.Legacy"? Configurable, anyway) or simply by
asking the user where they want them (which seems to be how most RISC
OS users like to operate anyway, myself included)?

Repositories could be created that don't necessarily hold any files
themselves, just index files full of locations of these zipfiles on
the web. All we'd need is for (and this could happen over time,
contributed to by many) people to add a few details of software they
know about to a master repository index file. These are basically just
software catalogs, as have existed in website form for years now.
Indeed, the index files could be created at first from those websites,
if people would oblige. Then, rather than each user having to find the
software catalog with a Google search, it's right there on their
desktop in the package manager.

Eg. I know about TopixWEB that hosts a number of now (I believe)
unmaintained software here: http://www.dnd.utwente.nl/topix/software/index.html
I could add to a repository index, eg.

   [URL<tab>Name<tab>Category<tab>Version<tab>Description]
{on multiple line for clarity}
   http://www.dnd.utwente.nl/topix/software/shrnkrma.zip
   AutoShrinkRMA
   Utilities
   Version 0.07 (01-Jan-96)
   AutoShrinkRMA will automatically try to shrink the size of the RMA
to a minimum.

etc., etc.

Once I'd done that for all the software on that site (not a huge
amount of work - I wouldn't even need to fill in every field
necessarily; !PackMan could just display " - Unknown - " if empty),
and the info was in a repository index, everyone else would be able to
find this software. Sure, they couldn't install it in a managed way,
but they could find it, which is the main point.

I think a crucial idea that's coming out of the above discussion is
that of sensible defaults. How should the package manager behave when
presented with a "package" that doesn't give much about itself away?
It's already been said that, by default, the manager could do a !Boot
merge / !System merge (and other resources merge) when it finds a
skeleton !Boot at the root level of the "package". It could also
perhaps probe the software to try to determine a version number. Then
if the user tried to install another metadata-less package with the
same name, the manager could give a warning that the version /may/ be
less that the current one. It could also attempt to find the Castle-
recommended AppName$Description system variable to give a description
of what the software does. Although this would mean the program's
reasonably modern (by RISC OS standards - god help us!) and hence
maybe still being maintained, so perhaps this would be of little
use...

But basically, these fake packages would just be a convenience, and
can't offer the benefits of full dependency management, or automatic
updating. It would be possible however, for people with large software
collections to rapidly create indices and therefore expose old,
unmaintained software to everyone.

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

#1418

In comp.sys.acorn.programmer Jess Hampshire <jesshampshire@googlemail.com> wrote:
> There should be the fall back option, where the packager presents a 
> list of packages which it will fetch for the user to install manually. 
> This would not need to involve the main underlying package mechanism. 
> This would just be a convenience feature, to help find software.

That would be reasonably easy to implement, but someone would have to
maintain such a list of descriptions and URLs.  Once you've done that, you
might as well run each one through PackIt and have proper packages.  But I
can see this being useful for cases where licensing forbids packaging
(slanted towards older software).

> The vast majority of items that would fall into this category would be 
> 26 bit programs, and they would be far less likely to be of interest 
> to a new Pi or BB user (i.e. of interest users who would be used to 
> having to find the software and then install it by hand).

I think 'flags' of 'ARM v4 OK' (A9), 'ARM v5 OK' (Iyonix), 'ARM v6 OK'
(RPi), 'ARM v7 OK' (OMAP - Beagle etc), 'StrongARM halfword OK' (emulators)
are becoming increasingly necessary.  Would there be a need for OS-level
flags (eg 'RO4 OK', 'RO5 OK' etc)?

> The other method would use a (manually created) packaging file that 
> contains the location of the archive and a mapping between the 
> locations of the contents and where they would be on a proper package.

That would solve licensing issues too... would be fairly easy to use and
create.

> There should also be a way of taking possesion of non managed items 
> once a managed version becomes available. There shouldn't be any 
> problems with modules, because they merge manually happily enough.

Yes.

> I would also like the front end to be a filesystem i.e. folders in 
> Resources:$ representing:

Interesting idea.  Would those have to be a full filing system (like
DeviceFS) or a pseudo Filer window (like Paint's sprites view)?  It would be
rather messy to have to implement all the packaging stuff in supervisor mode for
the former.
 
Theo

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

#1419

On 25 Jan 2012 16:18:12 +0000 (GMT), Theo Markettos 
<theom+news@chiark.greenend.org.uk> wrote:

> I think 'flags' of 'ARM v4 OK' (A9), 'ARM v5 OK' (Iyonix), 'ARM v6 
OK'
> (RPi), 'ARM v7 OK' (OMAP - Beagle etc), 'StrongARM halfword OK' 
(emulators)
> are becoming increasingly necessary.

Certainly, and don't forget the StrongARM flag is also useful for 
those with more lowly processors (for example, my 710 doesn't do long 
multiply).


> Would there be a need for OS-level flags (eg 'RO4 OK', 'RO5 OK' 
etc)?

Yes. I generic program shouldn't need it, but anything that uses a 
system-specific feature will want to flag this.

It might be an idea, also, to have a "32 bit" flag, where it isn't so 
specifc as to what version of RISC OS it will run on, but more what 
sort it WON'T.  This, especially, as we cannot rely upon RISC OS 6 
doing all RO5 could and more - the numbering is no longer sequential.

I like the idea of a hybrid for packaging and also linking to 
archives (in the case of older software). The thing is, how is a 
pointy-clicky package manager and installer (for surely that is what 
we are trying to achieve ultimately [*]) going to know what to do 
with an application in an archive. You can't blindly install it, in 
case it is itself an installer!

The most consistent UI approach would be a pseudo filing system, 
however as you say, it is a lot of code in a privileged mode. Even 
having a small Image FS to do display with a backend fetching the 
data is... a bit messy.

 
* - It might be good to stop thinking like programmers and instead 
work this one backwards. 1. What are we trying to achieve? 2. What 
will it look like? 3. What functionality will it provide users? When 
those concepts are clear, the technical specification will become 
clearer. For example, if a one-click managed install is what we're 
aiming for, then supporting random disparate zip files with no 
defined internal structure or control file is not really feasible. If 
we would like a check for updates option, it doesn't make sense to 
check 100 different files on 100 different websites if there is no 
agreed mechanism short of downloading and CRCing the files. Not to 
mention the delays in resolving and fetching numerous (hopefully) 
short files.
I ask this because while good ideas have come forth, we seem to have 
gone from a managed repo idea (and, yes, that implies a centralised 
resource, but the software doesn't need to be tied to one repo only) 
to something akin, frankly, to a mess with the potential of stuff 
scattered wherever. So perhaps we ought to take off our programmer 
hats and step back and ask "what is it we're trying to do here?". 


Best wishes,

Rick.

-- 
Best wishes,

Rick.

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

#1378

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

> The fact is: creating and maintaining a repository is not trivial, and the
> package format itself currently has an extremely high technical barrier to
> entry.  I know you desperately want to force everyone to do it 'properly'
> straight from the get-go, but that's not a credible proposition except with
> the aid of ludicrous amounts of optimism.

I'm not desperately wanting to force everyone to do anything of the kind. 
I'm open-minded as to what the solution should be, but in your previous posts
you had not explained clearly enough (to me, at any rate) what the advantages
were of your proposals.

I can see that being able to construct a list of dependencies just pointing
at zip files which are already out there has something to commend it.

I agree with Theo that the installer tool will have to be an awful lot
cleverer than a cleverer version of RiscPkg would be, because it has to cope
with complete absence of machine-readable instructions as to what to do with
stuff.

Do you have a suggestion for how metadata might be provided for a zip file
other than via a .txt file at a similar URL?  I'm thinking of the case where
author A wants to package his software and indicate that it depends on
application B.  The author of B is not interested in providing metadata, but
B is sufficiently complicated to install that it needs special instructions. 
Can author A provide metadata for app. B in the metadata file for his own
application?

I'm not convinced yet that your scheme is workable, but I'm thinking it over
now you've explained it a bit more clearly.  Would your proposal be able to
cope with installing software from thee xisting repositories too?  I can't
see the Unix ports moving over to a different competing scheme very quickly,
so whatever is the next generation solution has to support what we currently
have, in my opinion.

-- 
Matthew Phillips
Durham

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

#1380

In comp.sys.acorn.apps Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> I'm not convinced yet that your scheme is workable, but I'm thinking it over
> now you've explained it a bit more clearly.  Would your proposal be able to
> cope with installing software from thee xisting repositories too?  I can't
> see the Unix ports moving over to a different competing scheme very quickly,

On that point, it's relatively trivial to rebuild the Unix ports to use a
different packaging format.  Simply adjust the packaging scripts to use the
new format, and rebuild.  The current gotcha is that a lot of the
upstream sources have moved underneath the autobuilder, so won't build any
more.  This needs fixing in any case, and isn't a huge job (just somebody
needs to do it).

Theo

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

#1386

The following bytes were arranged on 19 Jan 2012 by Matthew Phillips :

> I agree with Theo that the installer tool will have to be an awful lot
> cleverer than a cleverer version of RiscPkg would be, because it has to cope
> with complete absence of machine-readable instructions as to what to do with
> stuff.

My intention isn't to make it clever at all.  Hardcoding a load of
bodges in the manager is asking for trouble - it should simply take a
'best guess' stab.  In 90% of cases, simply merging any apps found in
the zip named !Boot, !Fonts or !System with their current equivalents
and offering a 'Save as' dialogue box for everything else will do
perfectly well.

I'm already thinking a sort of 'Preview' window, to allow you to see
where everything in the zip is going to end up, is necessary anyway, and
in the case of zips without instructions it should probably be made
compulsory.  Then, if it gets it wrong, you can cancel the process and
install manually - but that won't happen very often.

> Do you have a suggestion for how metadata might be provided for a zip file
> other than via a .txt file at a similar URL?  I'm thinking of the case where
> author A wants to package his software and indicate that it depends on
> application B.  The author of B is not interested in providing metadata, but
> B is sufficiently complicated to install that it needs special instructions.
> Can author A provide metadata for app. B in the metadata file for his own
> application?

The problem with that is that said metadata would need to be duplicated
across all packages which depend on app B.  Again, I think that would be
asking for trouble.  If the manager can't decide, it should simply ask
the user.

> I'm not convinced yet that your scheme is workable, but I'm thinking it over
> now you've explained it a bit more clearly.  Would your proposal be able to
> cope with installing software from thee xisting repositories too?  I can't
> see the Unix ports moving over to a different competing scheme very quickly,
> so whatever is the next generation solution has to support what we currently
> have, in my opinion.

The current package format has a lot of structure and special files
which my proposition doesn't - in fact, that was one of my main
motivations for demanding that it be kept as simple as possible, because
there's currently absolutely no way for anything to be interpretable by
RiscPkg unless it was built that way deliberately, which takes quite a
bit of effort.  If you tried, it'd probably get very confused with the
RiscPkg.Control and RiscPkg.Copyright files, as well as anything lurking
in Sprites or SysVars.

I'd like to see no compulsory metadata within the archive itself at all
(especially given that the RiscPkg.Control file is just a subset of the
information in the server's own Index file), just a skeleton !Boot
structure in the root, with everything else being files to install.  The
problem with that is that it eliminates the ability to install
'offline', since you don't know what version it is, what its
dependencies are, etc.  Possibly there could be a one-line file
containing the package URL, but this would still make software pretty
much uninstallable on RISC OS computers without network connections
(yes, there are quite a few).

Given that dependency resolution is infeasible without a network anyway,
it's debatable how desirable this feature would be in any case, but it
may be worth implementing a 'fallback'.  Download the package on a
connected computer, and select a special option which rolls all the
dependencies and metadata into a mega-package suitable for export and
import to the unconnected computer's manager.  This, however, should
probably be filed under "we're not made of developer time".

I really need to set out all this in one place somewhere, because I can
tell people are getting very confused...

-- 
  __<^>__   Red sky in the morning: Shepherd's warning
 / _   _ \  Red sky at night: Shepherd's delight
( ( |_| ) ) Mince and potatoes: Shepherd's pie
 \_>   <_/  ======================= Martin Bazley ==========================

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

#1388

In message <1e68aa5452.martin@blueyonder.co.uk>
 on 20 Jan 2012 Martin Bazley  wrote:

> I really need to set out all this in one place somewhere, because I can
> tell people are getting very confused...

I don't think I missed any posts, but bear in mind when reading a thread that
you don't necessarily end up reading them in chronological order.

When Theo asks you about how your scheme does dependency checking, and you
say it doesn't, it's very confusing if you then say it does!  I guess you
thought Theo was asking about your minimum level bodge but I thoght he was
asking about your full scheme.

I am going to withdraw from this discussion until you've had time to step
back and write up a more cogent outline of how your scheme works, and maybe
Theo could do the same, though I think I've understood what he's proposing
rather better.  That may not be your fault of course!

-- 
Matthew Phillips
Durham

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

#1389

In comp.sys.acorn.apps Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> My intention isn't to make it clever at all.  Hardcoding a load of
> bodges in the manager is asking for trouble - it should simply take a
> 'best guess' stab.  In 90% of cases, simply merging any apps found in
> the zip named !Boot, !Fonts or !System with their current equivalents
> and offering a 'Save as' dialogue box for everything else will do
> perfectly well.

OK, let's measure it.  I take the list at:
http://www.riscos.info/index.php/Recommended_software
since that's short and relatively recently updated, and has a high Google
ranking.  I'm skipping the commercial programs and taking them in the order
they're listed on that page [first 5 sections of actual programs].  I'm not
installing stuff, I'm just reading the instructions.  Page down a bit to cut
to the chase.


StrongED:
StrED_cfg would be installed at same level as StrongED - this works, but it
might be better in Choices.  Won't install extra modes, since they're a
separate Zip.

Vim:
Needs SUL,Zapredraw, ZapFonts

Zap:
Points to out of date main Zap site, not ARMv7 version
Needs installation of !ZapFonts in System, !ZapUser in Choices (no skeleton
!Boot provided)

Director:
Drag and drop installation, but instructions have a fairly complex upgrade
procedure from earlier versions.  Extra plugins need separate installation
(skeleton !Director app buried 3 directories down that wants copying over
main app)

Infozip:
Drag and drop install

Memphis3
Drag and drop install

RiscPkg
No comment ;-)  [ignored for the purposes of the stats]

SparkPlug
In a SparkPlug archive (WTF?) not a Zip, so I can't look inside under Linux. 
Assumed drag and drop for the stats.

StrongHelp
Link broken

Thump
Drag and drop install.  Optionally needs Png2Spr.  Non-trivial update
instructions

Messenger (non-Pro)
Needs Newsbase, POPStar and Newshound

Cretin
Needs ZapFonts

LIRC
Drag and drop install

Parmesan
Link broken

Avalanche
Drag and drop install.  Optionally needs SysLog and ConfigX

ctorrent
bare command line program.  Needs SUL

Firefox
Needs SUL, Tinct, UnixHome.  Non-trivial upgrade procedure

FTPc
Needs Toolbox, Mimemap (these should probably be as standard anyway, ignored
for survey purposes).  Drag and drop install

NetSurf
Previously needed AcornURI, Iconv, SUL, Tinct but now bundled [dependency
fail].  Drag and drop plus Boot/Sys merge

Nettle
Needs ZapRedraw and ZapFonts, but has its own (non-32bit) internally for
backup (dependency fail)

WebJames
Slighlty non-trivial upgrade procedure.  Drag and drog install.


I'm sure you've got bored by now, so anyway here's the stats.  A 'drag and
drop' install is a simple copy of application directory and Boot/Sys Merge
where skeleton apps are found in the top level of the archive.  I ignore
other files (like sample documents) on the assumption that these could be
put next to the application in the same copy operation.

Number of programs surveyed: 20
Number of programs 404 or similar: 2
Programs with dependencies: 10/18
Programs to give any functionality with drag and drop install w/o dependency
resolution: 11/18
Programs to give full functionality with drag and drop install w/o
dependency resolution: 7/18
Programs to give full functionality with D'n'D when dependencies satisfied:
13/18
Programs that do not mention upgrade complications: 15/18

I hope you can see that a good chunk of programs aren't trivially
installable, and a surprising proportion have non-system dependencies.

> I'm already thinking a sort of 'Preview' window, to allow you to see
> where everything in the zip is going to end up, is necessary anyway, and
> in the case of zips without instructions it should probably be made
> compulsory.  Then, if it gets it wrong, you can cancel the process and
> install manually - but that won't happen very often.

The difficulty with this is it doesn't scale.  Fine for 2 programs, a pain
for 20, a nightmare for 200.

> The problem with that is that said metadata would need to be duplicated
> across all packages which depend on app B.  Again, I think that would be
> asking for trouble.  If the manager can't decide, it should simply ask
> the user.

The metadata could be picked up from somewhere else potentially (equivalent
to packaging it under this scheme).  This also isn't very friendly for new
users (who may not have the skills to follow installation instructions).

> The current package format has a lot of structure and special files
> which my proposition doesn't - in fact, that was one of my main
> motivations for demanding that it be kept as simple as possible, because
> there's currently absolutely no way for anything to be interpretable by
> RiscPkg unless it was built that way deliberately, which takes quite a
> bit of effort.  If you tried, it'd probably get very confused with the
> RiscPkg.Control and RiscPkg.Copyright files, as well as anything lurking
> in Sprites or SysVars.

As my numbers suggest, a lot of programs are not installable without some
kind of direction.  I agree, though, that the RiscPkg layout is not very
user friendly...  for example, why doese it have System.310 rather than
!System.Modules.310?  The latter can be given to a SysMerge tool to install
manually, the former cannot.

> I'd like to see no compulsory metadata within the archive itself at all
> (especially given that the RiscPkg.Control file is just a subset of the
> information in the server's own Index file), just a skeleton !Boot
> structure in the root, with everything else being files to install.  The
> problem with that is that it eliminates the ability to install
> 'offline', since you don't know what version it is, what its
> dependencies are, etc.  Possibly there could be a one-line file
> containing the package URL, but this would still make software pretty
> much uninstallable on RISC OS computers without network connections
> (yes, there are quite a few).

How do you tie a timestamped archive (foo.zip 2012-01-20 20:54:33) to
version information?  How do you know how it differs in version from
(foo.zip 2011-12-22 15:22:55).  It differs, yes, but how do I tie the
'pointer' metadata file to each of these?  Hashes is one way, I suppose, to
check if the contents have changed.  But if the contents /have/ changed
(which could be as simple as changing the datestamps on the files in the
Zip, rather than anything more) what does that signify?

One issue with your check-the-datestamp idea is that authors tend to call
zipfiles progname-v123.zip not progname.zip - a script checking this won't
notice that progname-v124.zip has been released.  That might be fine if you
insist on a 'pointer' file, but then someone has to update that file for
each update.

> I really need to set out all this in one place somewhere, because I can
> tell people are getting very confused...

That would be helpful :)  I think we're starting to emit more heat and not
much more light...

Theo

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

#1390

The following bytes were arranged on 20 Jan 2012 by Theo Markettos :

> In comp.sys.acorn.apps Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> > My intention isn't to make it clever at all.  Hardcoding a load of
> > bodges in the manager is asking for trouble - it should simply take a
> > 'best guess' stab.  In 90% of cases, simply merging any apps found in
> > the zip named !Boot, !Fonts or !System with their current equivalents
> > and offering a 'Save as' dialogue box for everything else will do
> > perfectly well.
>
> OK, let's measure it.  I take the list at:
> http://www.riscos.info/index.php/Recommended_software
> since that's short and relatively recently updated, and has a high Google
> ranking.  I'm skipping the commercial programs and taking them in the order
> they're listed on that page [first 5 sections of actual programs].  I'm not
> installing stuff, I'm just reading the instructions.  Page down a bit to cut
> to the chase.

[snip]

That's certainly a bit of an eccentric list of 'recommended software',
although, I suppose, not entirely surprising when I see what website it
came from.  A lot of it's outdated (Messenger), incompatible (LIRC) or
redundant from the perspective of a new RISC OS user (Firefox).  I
certainly wouldn't include Vim or Nettle in any shopping list for the
newbie casual user.  One rather glaring absence is DigitalCD, which
probably has the most nightmarish installation procedure of the lot.

That reminds me: if there isn't already (I've never found one), there
needs to be a utility to automate merging of MimeMap files.

The thing about considering 'recommended' software, even allowing for
the peculiar choices in your list, is that, due to the frequently
complex functions that RISC OS's best-loved software performs, it
follows that they have the most complex install and upgrade procedures,
which skews your statistics substantially.  You can't compare the
installation of StrongED with that of, say, UnitConv.  And once you've
got NetSurf, StrongED/Zap, StrongHelp, DigitalCD, Director/StrongMen,
give or take a few, you've pretty much exhausted the
common-but-complex-to-install software on offer.  The tricky first step
will be getting all the major freeware on board, because I've never
pretended that faked-up packaging would be suitable for anything
non-trivial to install.

Just as it takes a certain 'critical mass' of software upgrades to
persuade people to buy a new, non-backward-compatible computer, so I
don't think we can decently expect anyone to seriously use packaging
until the essentials are packaged.

A quick browse through my own website's downloads folder (the home of
Infozip, incidentally) suggests that, once C library and Toolbox
dependencies are taken out, a small minority is dependent on components
not distributed in the same zip, and most installations is a simple
matter of drag and drop.  Then again, I wouldn't call most of that
'recommended' software (except insofar as I recommend a lot of it).

To give you an idea of what sort of software I consider suitable for
automatic installation, here's a quick browse through one directory on
my hard disc (you can probably guess which one):

ArtToSpr: Requires Toolbox/AWRender
BMPSprite: Trivial
Calibre: Trivial
ChangeFSI: Trivial/bundled
Cogs: Trivial (personal guarantee of author)
ExifEdit: Toolbox/trivial
FSI_Batch: Trivial
Grab2: Toolbox/trivial
OpenGridPro: Trivial
OpenVector: Trivial
PhotoFiler: Trivial (AWRender optional)
Etc. etc.

No, of course automatic installation isn't a suitable replacement for
packaging, but until such time as everything is packaged, it can fill
the gap in most cases.

NB: You should take care not to confuse the principle of 'running out of
the box' with 'working out of the box'.  MBBack, for example, refuses to
run until you configure a list of backdrops to display, but that doesn't
mean you can't install it by drag and drop - it'll even automatically
create all the files in Scrap and Choices that it requires when first
run.

> > I'm already thinking a sort of 'Preview' window, to allow you to see
> > where everything in the zip is going to end up, is necessary anyway, and
> > in the case of zips without instructions it should probably be made
> > compulsory.  Then, if it gets it wrong, you can cancel the process and
> > install manually - but that won't happen very often.
>
> The difficulty with this is it doesn't scale.  Fine for 2 programs, a pain
> for 20, a nightmare for 200.

It doesn't have to.  How would you find yourself installing more than
three or four programs - absolute maximum - at once?  The only plausible
circumstance is the setting-up of a virgin system, and (as your survey
established) non-directed installation really wouldn't work for a lot of
the software you'd generally install by default, such as Zap.

> > The problem with that is that said metadata would need to be duplicated
> > across all packages which depend on app B.  Again, I think that would be
> > asking for trouble.  If the manager can't decide, it should simply ask
> > the user.
>
> The metadata could be picked up from somewhere else potentially (equivalent
> to packaging it under this scheme).  This also isn't very friendly for new
> users (who may not have the skills to follow installation instructions).

I suppose it'd be possible to have the metadata hosted separately from
the zip, but by the time you've got to that stage you have to ask
yourself why the software isn't packaged in the first place.  This also
wouldn't be helpful in cases where the installation is so complex it
requires a script.

I suppose any installation scripts could be stored actually *in* the
metadata file, as star commands (with a few system variables set up
before execution), which would solve that problem.  I haven't really
given any thought about scripting yet, but I suppose that software
could, in extremis, be packaged by the back door while not moving from
its original webspace, simply by distributing a script to take care of
the nasty bits.

> > I'd like to see no compulsory metadata within the archive itself at all
> > (especially given that the RiscPkg.Control file is just a subset of the
> > information in the server's own Index file), just a skeleton !Boot
> > structure in the root, with everything else being files to install.  The
> > problem with that is that it eliminates the ability to install
> > 'offline', since you don't know what version it is, what its
> > dependencies are, etc.  Possibly there could be a one-line file
> > containing the package URL, but this would still make software pretty
> > much uninstallable on RISC OS computers without network connections
> > (yes, there are quite a few).
>
> How do you tie a timestamped archive (foo.zip 2012-01-20 20:54:33) to
> version information?  How do you know how it differs in version from
> (foo.zip 2011-12-22 15:22:55).  It differs, yes, but how do I tie the
> 'pointer' metadata file to each of these?  Hashes is one way, I suppose, to
> check if the contents have changed.  But if the contents /have/ changed
> (which could be as simple as changing the datestamps on the files in the
> Zip, rather than anything more) what does that signify?

I don't understand your problem here.  I can only assume we're talking
at cross-purposes (see below)

> One issue with your check-the-datestamp idea is that authors tend to call
> zipfiles progname-v123.zip not progname.zip - a script checking this won't
> notice that progname-v124.zip has been released.  That might be fine if you
> insist on a 'pointer' file, but then someone has to update that file for
> each update.

None of my zips do that, but, yes, that would be a problem.

> > I really need to set out all this in one place somewhere, because I can
> > tell people are getting very confused...
>
> That would be helpful :)  I think we're starting to emit more heat and not
> much more light...

From reading your response, as well as Matthew's, everybody seems to
have jumped to the mistaken conclusion that I've performed a volte face
and am now rejecting the idea of metadata altogether.  This is *not* the
case.  Checking the datestamp and attempting to install automatically is
*not* my proposal for a packaging system - it's an add-on to my proposal
for an actual packaging system, which, when it works (which it won't for
all software), gives existing non-packaged software a leg up into the
real thing, encouraging takeup of the manager by users who can still get
most of their old software, even the ones which haven't been packaged
yet.

I hope that the ranks of such software will dwindle as time goes by,
just as most software is now 32-bit compatible, but it will be a
majority at first - which will harm takeup by users, which will harm
takeup by developers who can't see why they should support something
hardly anybody uses, which will harm takeup, and so on in a vicious
circle.  Bodging in as much of the missing software as possible is
better than denying access to it altogether.

-- 
  __<^>__   === RISC OS is a work of art.  Some people adore it,  ===
 / _   _ \  === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive.                                        ===
 \_>   <_/  ======================= Martin Bazley ===================

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

#1393

On Sat, 21 Jan 2012 00:51:38 GMT, Martin Bazley 
<martin.bazley@blueyonder.co.uk> wrote:

> needs to be a utility to automate merging of MimeMap files.

Packager with helper util could have this sorted. ;)


> I don't think we can decently expect anyone to seriously use 
packaging
> until the essentials are packaged.

Okay. I'll commit. There is an eccentric load of crap on my site, 
however give me a nice packager and I will package up *the* *lot*. 
Might not be "essentials", but we have to start somewhere! [anybody 
else willing to commit likewise at this early stage?]

Give me a way, I'll even make sources available for some stuff - I 
don't see why a packager couldn't sort that out too...


Best wishes,

Rick.

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

#1397

In comp.sys.acorn.apps Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> From reading your response, as well as Matthew's, everybody seems to
> have jumped to the mistaken conclusion that I've performed a volte face
> and am now rejecting the idea of metadata altogether.  This is *not* the
> case.  Checking the datestamp and attempting to install automatically is
> *not* my proposal for a packaging system - it's an add-on to my proposal
> for an actual packaging system, which, when it works (which it won't for
> all software), gives existing non-packaged software a leg up into the
> real thing, encouraging takeup of the manager by users who can still get
> most of their old software, even the ones which haven't been packaged
> yet.

Ah, I think I'm beginning to understand - please correct me if I'm wrong
here.  For 'complicated' software, like the heavyweight apps on the list,
you would have them packaged with metadata by some means you've yet to
describe.  For 'simple' software, by which I mean the tiny little utilities
like UnitConv, ideally they would be packaged but it's possible to get by
without packaging them.  For example, drag the Zip to the package manager,
it figures out what to do with it, offers a Save box but also makes a note
of what got installed where so it can upgrade it/etc as necessary.  Using
the riscpkg:// URL scheme to indicate the position of the Zip would also
record it to do the checking for updates as well.

That sounds workable, though I think the progname-v123.zip is a bigger
problem than you realise (I don't have the archives from my survey, but a
good number used that naming scheme).  That's fairly straightforward to work
around though (server symlink, or simply copy the file twice).

It slightly depends on your emphasis though... I think apps like Zap and
NetSurf are the ones that would benefit most from the package manager.  It
doesn't benefit UnitConv that much, because manual installation is trivial
and the pressure for upgrading is less.  But I agree that there are lots of
little apps out there, and it would get tedious if you wanted to
install/upgrade large batches of them.

I think we've gone around in circles a bit regarding metadata, obsoleting
and discovery, so if you could set down your ideas in one go that might be
handy.

Anyway, thanks for your continuing engagement in this topic :)

Theo

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

#1392

On 20 Jan 2012 21:10:42 +0000 (GMT), Theo Markettos 
<theom+news@chiark.greenend.org.uk> wrote:

> As my numbers suggest, 
...

...we RISC OS users are long term and generally "just know" how to do 
this stuff. If we're to attract newbies, will we do so like this? 
Yes, it is neat to drag'n'drop to install, but as you say, as soon as 
dependencies are involved, it gets a while lot harder.

Example - I have NettleSSH. It came as-is. It needs ZapRedraw. No 
probs, got that. It wants SocketWatch. Umm... Gave up looking for 
that (got bored). This was *after* installing and finding that it 
doesn't work.

Not to mention, as I and others say, tagging with processor type 
information would be useful, perhaps with an active filter. No point 
installing 26bit software on a Beagle; nor an MP3 player on an ARM710 
(uses UMULL...).


Best wishes,

Rick.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web