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

Groups > comp.sys.acorn.apps > #2737 > unrolled thread

Fresh packaging ideas

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

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 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 Dave Symes <dave@triffid.co.uk> - 2012-01-21 19:09 +0000
                          Re: Fresh packaging ideas Ron Briscoe <ron.briscoe@blueyonder.co.uk> - 2012-01-21 20:18 +0000
                            Re: Fresh packaging ideas Patric@invalid.com - 2012-01-21 23:21 +0100
                          Re: Fresh packaging ideas Stuart <Spambin@argonet.co.uk> - 2012-01-21 23:28 +0000
                  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
        Re: Fresh packaging ideas Chris Johnson <chrisjohnson+news@spamcop.net> - 2012-01-17 17:02 +0000
          Re: Fresh packaging ideas Tim Hill <tim@invalid.org.uk> - 2012-01-21 15:12 +0000
    Re: Fresh packaging ideas  <news@iank.org.uk> - 2012-01-28 12:19 +0000

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

#2798

In comp.sys.acorn.apps Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> 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.

I think you misunderstand what a repository is.  It supplies two things, a
Packages file (a list of the packages available) and some package archives.

Actually, the Packages file already contains URLs to each package archive. 
So a putative repository replacement merely has to fabricate a suitable
Packages file, where the URLs can go off all over the place.  The Packages
file is a necessity because it holds the dependency and description
information but it, or the data structures that represent it, could easily
be built from another source by libpkg.

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

The 'distributed repo' idea has some merits... as long as the risks can be
kept under control too.

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

The question becomes, how do you get a full picture of what's available? 
ProgX depends on libFoo and BarMod.  I know the location of ProgX, but how
do I find libFoo and BarMod?  Bearing in mind that libFoo might have
recently moved servers, so that only the old version is at the site the
ProgX author knew about 5 years ago when they wrote their program.  Unless
you have some kind of package search service, which starts looking like a
repo by another name (even if the actual archives are hosted on authors'
sites).

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

Yes, that was one of my suggestions... a normal Zip but with some additional
instructions to the package manager as to what should go where.

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

Without dependency resolution or update checking you're essentially
suggesting a simple Windows-style install wizard.  Which is fine, but it's
not that useful on RISC OS (where drag and drop installs are simple anyway,
give or take SysMerge etc).

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

Such could be generated from the 'packaging wizard' - PackIt or similar.

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

I think I'm failing to understand - won't that mean the file always comes up
as 'new', even if it isn't?

Date stamps are a bit vulnerable at the server end: if you have to restore
from backup and end up mangling the dates for some reason, you'd force
everyone 'out there' to upgrade for no reason.

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

But who is managing this list of outdated dependency URLs?  By definition,
the person who created the old URL is unlikely to deprecate it.  So someone
else has to declare the URL outdated.  Do you have 'dependency police', or
can someone declare that someone else's work is outdated?  How do you manage
that?

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

Android has the market:// URL format in a similar way... it works, but it's
something of a pain if you're browsing on a non-Android device since it's
used not only to install an app, but merely to find out about it (and some
Android devices can't use Market at all).  After several years they got
around to making a website with the same information.

But having it merely as an install mechanism, and with a parallel http://
way to download the archive for manual inspection, might be OK.

A web of links as you suggest sounds OK, though would have to think about
the corner cases.

What would be your initial conditions?  You download the package manager
on a blank machine.  How does it find out about software you might want to
install?

Theo

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

#2803

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

> In comp.sys.acorn.apps Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> > 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.
>
> I think you misunderstand what a repository is.  It supplies two things, a
> Packages file (a list of the packages available) and some package archives.

I know perfectly well what a repository is, thank you.

> Actually, the Packages file already contains URLs to each package archive.
> So a putative repository replacement merely has to fabricate a suitable
> Packages file, where the URLs can go off all over the place.  The Packages
> file is a necessity because it holds the dependency and description
> information but it, or the data structures that represent it, could easily
> be built from another source by libpkg.

The Packages file (or the Index file, as RiscPkg calls them) contains
nothing of the sort.  Both dependency and description information are
individually stored in each zip, in a file called RiscPkg.Control, and
all the Index file does is copy all of this information into a long list
in one file.  Believe me - I've built them.

I don't think you understood my proposal for URLs, either.  I'm not
suggesting a different way of associating URLs with package names - I'm
suggesting replacing package names *with* the URLs entirely.  They're
guaranteed to be unique, after all.

PackMan and the RiscPkg front-end already ship with a default list of
available packages, in the form of a link to the RiscPkg repo.  Why
couldn't such a thing be moved offline and distributed with each
archive?

> > 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.
>
> The 'distributed repo' idea has some merits... as long as the risks can be
> kept under control too.

The main risk is that of software moving locations or being abandoned
and taken up by someone else, which can be viewed as very much as the
inverse of the notorious problem of managed data moving (or even being
copied) on a hard disc - i.e. easily surmountable.

> > 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.)
>
> The question becomes, how do you get a full picture of what's available?
> ProgX depends on libFoo and BarMod.  I know the location of ProgX, but how
> do I find libFoo and BarMod?  Bearing in mind that libFoo might have
> recently moved servers, so that only the old version is at the site
> the ProgX author knew about 5 years ago when they wrote their program.

That was precisely the sort of circumstance I was thinking about when I
wrote the paragraph above.  I went into more detail later (so keep
reading).

> > 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).
>
> Yes, that was one of my suggestions... a normal Zip but with some additional
> instructions to the package manager as to what should go where.

Exactly - but *without* the additional instructions, so any given zip
currently available (or at least most of them) could theoretically be
used in this manner.  It should be default behaviour for the manager to
scan the archive for directories called !Boot, !System or !Fonts anyway,
so it wouldn't be entirely dumb.  Of course, additional instructions
should preferably be made available, in order to gain the maximum
benefit - but we've got to start somewhere, otherwise we'll never get
started.

> > 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.
>
> Without dependency resolution or update checking you're essentially
> suggesting a simple Windows-style install wizard.  Which is fine, but it's
> not that useful on RISC OS (where drag and drop installs are simple anyway,
> give or take SysMerge etc).

Precisely - not that useful, but it's something to start from.  There's
a criminal lack of understanding in this thread of the fact that we
*need* somewhere to start from, no matter how primitive it may be at
first - and 'starting from' the current libpkg codebase will just
maintain the current woeful situation (most software unavailable, the
rest packaged by third parties with all the usual problems with that) in
perpetuity.

> > 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.
>
> Such could be generated from the 'packaging wizard' - PackIt or similar.

It would probably end up that way, yes.

> > 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.)
>
> I think I'm failing to understand - won't that mean the file always comes up
> as 'new', even if it isn't?

Only if, for whatever reason, the file on the server continually had its
datestamp changed.  I'm hoping that doesn't happen in practice.
Certainly, if you were to install any of my software that way, it would
definitely work.

> Date stamps are a bit vulnerable at the server end: if you have to restore
> from backup and end up mangling the dates for some reason, you'd force
> everyone 'out there' to upgrade for no reason.

Yep.  I didn't say it was perfect, and a metadata file would guard
against this.

> > 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.
>
> But who is managing this list of outdated dependency URLs?

Nobody.

> By definition, the person who created the old URL is unlikely to
> deprecate it.

Unless they planned to move their website.

> So someone else has to declare the URL outdated.

That'll be the person who wrote the superseding version in the first
place, then.

> Do you have 'dependency police', or can someone declare that someone
> else's work is outdated?  How do you manage that?

Like this:

PackageURL: riscpkg://example.com/libfoo/libfoo.txt
ObsoleteURLs: riscpkg://example.com/libfoo/libfoo_patch.txt,
riscpkg://other.website.com/software/libfoo/libfoo_ancient.txt

The zip file of the package itself would be the same as the metadata
file itself (so the PackageURL field would actually be the URL of the
exact same file it was read from), but ending in ".zip".  If any of
these URLs (or any URLs, really) ended in ".zip", the manager would
first check for an equivalent ".txt" (just in case the file was updated
to package format) and use that instead if found, otherwise fall back to
the 'install wizard' solution.

Naturally, the manager would maintain an offline database of all known
URLs, *including* the obsolete ones - precisely so it could check any
requested dependencies against them.  Even if you're installing libfoo
for the very first time, you'd still get all of its obsolete locations
as well.

The tricky bit is announcing the new home of libfoo.  In many ways, the
situation is very similar today (if people don't see the announcement
and keep checking the previous home page, they'll never have the new
one, and there's not much that can be done about that), but ideally, the
new maintainer would post on such as csa.announce the new URL, which
would point to the metadata, and when you clicked on it, the manager
would spot an entry in its "ObsoleteURLs" field which matched the name
of a package you already had installed, and update it for you.

In the planned move scenario, the libfoo_patch file would contain
exactly the same two fields, which would also be interpreted as a prompt
to update the local database, since the "PackageURL" didn't match the
URL of the file it was just read from.

That leaves as the remaining vulnerability users who install software
which lists an obsolete location of a dependency they don't have.  If
it's still there, then it'll be installed with no questions asked, which
poses the only real hazard.  Fortunately, it should also be fairly rare
(or at least no more common than it is now, which goes with my mantra
that fixing old problems isn't worth creating new ones).

> > 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.)
>
> Android has the market:// URL format in a similar way... it works, but it's
> something of a pain if you're browsing on a non-Android device since it's
> used not only to install an app, but merely to find out about it (and some
> Android devices can't use Market at all).  After several years they got
> around to making a website with the same information.
>
> But having it merely as an install mechanism, and with a parallel http://
> way to download the archive for manual inspection, might be OK.

That would be included pretty much by definition.  The idea is that a
click on a riscpkg:// URL would add the data contained by the metadata
file or (if applicable) datestamp on the other end to the local
database, and then ask you if you want to install the file.  Answering
no would keep the location on the database for possible future
installation.

Interpreting a file full of such URLs would shortcut all this (and not
bring up the dialogue box for each one, since it would be redundant and
a nuisance), and be the standard way of populating an empty database.
Shipping one of these with the manager itself would do nicely, or
possibly have the manager come with only one entry preinstalled, which
is a list of default package URLs hosted on its own home page (with
priority set to 'required').

Updating this list would also be a neat fallback solution for the
obsolete dependency problem, forcing everybody to update the offending
entry in their local databases the moment they launch the manager.  Of
course, this is rather like a repo, but with the rather important
difference that it isn't compulsory for software to be in it.  As I
believe I said in my last post, repos are neater and have many
advantages, but most of these evaporate the moment you outlaw software
outside them.

> A web of links as you suggest sounds OK, though would have to think about
> the corner cases.

> What would be your initial conditions?  You download the package manager
> on a blank machine.  How does it find out about software you might want to
> install?

Well, as my proposals are mostly about finding sensible defaults, it
follows that the package manager wouldn't be distributed with an
absolutely blank database file, but one already filled up with as many
entries as possible, covering all common software and dependencies, and
hopefully most uncommon ones as well.  (Or with a list/link to list
suitable for automatic interpreting; see above.)

Getting more would simply be a matter of using Google (as opposed to the
much more unfriendly package search services which Linux has) to find
the software's home page, clicking on the presented riscpkg:// URL, and
selecting "Install now" on the resulting dialogue box.

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

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

#2815

In article <e9c52c5452.martin@blueyonder.co.uk>, Martin Bazley
<URL:mailto:martin.bazley@blueyonder.co.uk> wrote:
> The following bytes were arranged on 19 Jan 2012 by Theo Markettos :
> 
> > In comp.sys.acorn.apps Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> > > 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.
> >
> > I think you misunderstand what a repository is.  It supplies two things, a
> > Packages file (a list of the packages available) and some package archives.
> 
> I know perfectly well what a repository is, thank you.

I think your comment highlights one of the problems in this discussion, in
that that you have an understanding of a term and the capabilities of the
thing the term is about (In this case a 'repository') Theo's idea of the
same thing will not be exactly the same as yours and mine will also be
different again (mine probably widely different as I've most likely not
understood it:-/ ).

> uptake will still be extremely low - and that is, quite simply,
> because most applications have not been packaged, and probably never
> will be.

Yes many programs are now mature and not being updated so don't need
packing. It is those are being regularly updated that need doing and will
benefit.

n.b. I've been following the thread and I am broadly speaking in favour of
packaging provided it is not the only way updates are provided. Keep
everyone happy.


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]

#2817

In message <ant2013531cbpErr@client.cjemicros.co.uk>
          Chris Evans <chris@cjemicros.co.uk> wrote:

> Yes many programs are now mature and not being updated so don't need
> packing. It is those are being regularly updated that need doing and will
> benefit.

> n.b. I've been following the thread and I am broadly speaking in favour of
> packaging provided it is not the only way updates are provided. Keep
> everyone happy.


Offering my 2p first of all allow me to say I'm all for packaging as I 
found getting into RISC OS a bit of a nightmare. Hours spent on 
browsing the web, searching for compatible modules (e.g. having fun 
with ROOL/ROL toolbox modules etc. on my BB), defunct websites like 
suddenrecoil.org via wayback machine and all that jazz.
Not the way to go really. Some of the problems seem to result from 
seasoned users being creatures of habit whereas the typical Raspberry 
Pi user won't have any objections concerning where to put what. In 
theory the advantages should be clear. OTOH having games in either 
"diversion", "games", "app.game" or "app.emulation.games" IS confusing 
to say the least.
A major problem however might be that browsing !PackMan won't give you 
a clue as to whether any of the programs actually run on your 
ARMv6/ARMv7 machine making it necessary for the inexperienced user to 
first of all trawl the net for information.

Of course the frustrating bit for any developer is that the typical 
user and I've been guilty of this myself, happily ignores ManPages or 
readme files :)

Anyway: the R-Pi will (hopefully) confront us with complete newbies. 
Their last experience with RISC OS could have been using it on the 
school's A3000 or none at all. That's going to be both a challenge and 
an opportunity but certainly something to keep in mind when talking 
about improving package management and software developement in 
general.


patric

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

#2837

On 20/01/2012 15:16, Patric@invalid.com wrote:
> Anyway: the R-Pi will (hopefully) confront us with complete newbies.

All clutching their new Kodak film cameras no doubt.

---druck

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

#2840

In message <jfe21q$vnn$2@dont-email.me>
     druck <news@druck.org.uk> wrote:

> On 20/01/2012 15:16, Patric@invalid.com wrote:
> > Anyway: the R-Pi will (hopefully) confront us with complete newbies.
> 
> All clutching their new Kodak film cameras no doubt.

Ooh, sharp! :-)

-- 
Fred

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

#2846

On Sat, 21 Jan 2012 09:55:07 +0000, druck <news@druck.org.uk> wrote:

> All clutching their new Kodak film cameras no doubt.

OI! Mock Kodak at your peril. To my mind, for PROPER photography (not 
this pointy clicky digital stuff), there is (was!) Kodak and there is 
Ilford. No exceptions.


Best wishes,

Rick (with some Kodak Super8 reels on the bookshelf).

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

#2847

In article <almarsoft.8063639546728836861@news.orange.fr>,
   Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> On Sat, 21 Jan 2012 09:55:07 +0000, druck <news@druck.org.uk> wrote:

> > All clutching their new Kodak film cameras no doubt.

> OI! Mock Kodak at your peril. To my mind, for PROPER photography (not 
> this pointy clicky digital stuff), there is (was!) Kodak and there is 
> Ilford. No exceptions.


> Best wishes,

> Rick (with some Kodak Super8 reels on the bookshelf).

Oh dear Rick, I used to be like you, then I had a play with digital...
Hooked... Line and sinker...

No more shut away in a dark-room, no more peering/squinting at enlarger
images, no more dodging or burning with various small paddle type
instruments, no more spotting-in negatives with inks and a 00 or 000
brush, no more noxious chemicals, etc ...

Instead after camera, I sit in my lighted office in a comfy chair, in
front of a fast computer, with a wide screen monitor, working on my
pictures in Paint Shop Pro with more imaging tools at my fingertips than I
could have imagined in my silver photography days.

I still have the silver kit, in a cupboard somewhere in the house, and
once in a Blue moment I take it out and have a play, but usually stick it
back in the cupboard again quite quickly...  ;-)

Dave

-- 

Dave Triffid

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

#2848

In article <52552aa35edave@triffid.co.uk>,
   Dave Symes <dave@triffid.co.uk> wrote:
> Oh dear Rick, I used to be like you, then I had a play with digital...
> Hooked... Line and sinker...

> No more shut away in a dark-room, no more peering/squinting at enlarger
> images, no more dodging or burning with various small paddle type
> instruments, no more spotting-in negatives with inks and a 00 or 000
> brush, no more noxious chemicals, etc ...

> Instead after camera, I sit in my lighted office in a comfy chair, in
> front of a fast computer, with a wide screen monitor, working on my
> pictures in Paint Shop Pro with more imaging tools at my fingertips than I
> could have imagined in my silver photography days.

Ever thought of cutting out the image manipulation and getting a decent
camera? ;-)).

[Snip Dave's plying with his silver kit.]

Regards Ron.

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

#2850

In message <525530f1ceron.briscoe@blueyonder.co.uk>
          Ron Briscoe <ron.briscoe@blueyonder.co.uk> wrote:

> In article <52552aa35edave@triffid.co.uk>,
>    Dave Symes <dave@triffid.co.uk> wrote:
>> Oh dear Rick, I used to be like you, then I had a play with digital...
>> Hooked... Line and sinker...

>> No more shut away in a dark-room, no more peering/squinting at enlarger
>> images, no more dodging or burning with various small paddle type
>> instruments, no more spotting-in negatives with inks and a 00 or 000
>> brush, no more noxious chemicals, etc ...

>> Instead after camera, I sit in my lighted office in a comfy chair, in
>> front of a fast computer, with a wide screen monitor, working on my
>> pictures in Paint Shop Pro with more imaging tools at my fingertips than I
>> could have imagined in my silver photography days.

> Ever thought of cutting out the image manipulation and getting a decent
> camera? ;-)).

> [Snip Dave's plying with his silver kit.]


Actually I'm still toying with the idea of getting myself a Holga

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

#2851

In article <52552aa35edave@triffid.co.uk>,
   Dave Symes <dave@triffid.co.uk> wrote:

> Oh dear Rick, I used to be like you, then I had a play with digital...
> Hooked... Line and sinker...

Ah well, when I can afford 600 quid for the 12-24mm wide angle for my
digital camera I'll stop using my 18-55 on my film camera.

<sigh>

Do I want that ARmini or not.

-- 
Stuart Winsor

Only plain text for emails
http://www.asciiribbon.org

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

#2830

On Fri, 20 Jan 2012 13:32:53 +0000, Chris Evans 
<chris@cjemicros.co.uk> wrote:

> n.b. I've been following the thread and I am broadly speaking in 
favour of
> packaging provided it is not the only way updates are provided. Keep
> everyone happy.

This is why I am in favour of Theo's zip-plus-something idea, as the 
packager can use the extra resource file(s), while a manual install 
can just draggy-droppy.

This said, having used Windows a while now (arrrgh! heretic!) it is 
like a luxury to run a file, ignore the licence, click a button, and 
it is all installed (DLLs and such too) without problem.

I mean, RISC OS is not an obfuscated heap of s... like C:\Windows, so 
having a nice clicky-easy installer should *not* present problems.

And objection (singular?) to repositories notwithstanding, it would 
be a real aid to have a nice category-based list of available 
software. Sure, we could look it up in a search engine, but that is 
SO last millennium! Hasn't the mindset of RISC OS users moved on 
since Acorn shut up shop? <stir> <stir>

I think it should be mandatory that everybody use a decent Windows 
based installer for a complicated setup (try Firefox or VLC), and 
then just browse the repository under Ubuntu. Not a quick look, but a 
serious examination. You'll see it isn't some sort of magic, and you 
might start asking "why doesn't RISC OS have this sort of stuff?".


Best wishes,

Rick.

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

#2856

On Jan 20, 1:32 pm, Chris Evans <ch...@cjemicros.co.uk> wrote:
> In article <e9c52c5452.mar...@blueyonder.co.uk>, Martin Bazley
>
> <URL:mailto:martin.baz...@blueyonder.co.uk> wrote:
> > The following bytes were arranged on 19 Jan 2012 by Theo Markettos :
>
[snip]
> > > I think you misunderstand what a repository is.  It supplies two things, a
> > > Packages file (a list of the packages available) and some package archives.
>
> > I know perfectly well what a repository is, thank you.
>
> I think your comment highlights one of the problems in this discussion, in
> that that you have an understanding of a term and the capabilities of the
> thing the term is about (In this case a 'repository') Theo's idea of the
> same thing will not be exactly the same as yours and mine will also be
> different again (mine probably widely different as I've most likely not
> understood it:-/ ).

I'll just add few comment about repositories as I see them on the
off chance it helps.

In the context of package management a repository is just a single
place for storing software with some extra information and indices
so you can browse for software. The extra information also contains
information to automatically install anything else need to run an
application
for you when you install the application you want.

The benefits I see to them are:

1. There is a single place where you can find and install software
from.
2. If you can get to the index, you can get to the software and it's
dependencies, as they all generate the indices from the packages
added to them. If it's in the index it's available in the repository.
3. They provide a browsable and searchable list of what they contain.
4. The provide an archive of software. If an author leaves the scene
or
loses or moves his website, then the software doesn't have to
vanish with him.
5. Each software author doesn't need to create and maintain his
own website just to distribute his applications.
6. It's has successfully been used as the basis for the distribution
of millions of application on a variety of different operating
systems.

The downsides are:

1. Someone has to create the package with the application
in it and add it to the repository.
2. It the repository goes down, you can't get any packages
until it comes back up again.
3. Multiple conflicting repositories could be created.
4. Link rot - i.e. The version of an application in the
repository isn't up to date with the latest and greatest
from the authors website.
5. Not all software may end up in the repository.

riscpkg has the following extras that I don't know if are
implemented by other repositories.

1. Allow multiple repositories to be contacted and merge
them into a single list presenting the latest version for
install. This does mean of course you could get everybody
deciding they need their own repository.
2. Any file that is in the package format can be dropped
onto the iconbar and made available for install so it does
not have to have come from a repository.

The idea of repositories isn't really as foreign to RISC OS
as it may sound. Just consider the pre-internet days when
you used a catalog to order collections of software on
a floppy disc.

>
> > uptake will still be extremely low - and that is, quite simply,
> > because most applications have not been packaged, and probably never
> > will be.
>
> Yes many programs are now mature and not being updated so don't need
> packing. It is those are being regularly updated that need doing and will
> benefit.

I think every useful program should be packaged, so people can have
and easy way to find and install them. Even an application that isn't
being updated at all would be made easier to install if it had any
dependencies.

Reallistically, you won't get anywhere near all the RISC OS programs
that were ever written into the repository. But if nobody cares about
a program or there is an alternative already in the repository, does
it
really matter?

When I decided to move to an Iyonix, I just looked to see if there
were enough 32bit programs to do what I wanted to with it. In the
case of moving to a repository it's not as drastic as that as you
can still find an install software as you do now even if it isn't in
the
repository.

Uptake is slow. A lack of time and people mean that it will take a
while for the repository to mature. I see promising signs of
developers starting to package their software or at least give
it a strong consideration. I'd like it to go faster, but I'd rather
build something that will be better in the long term than go
for a quick fix that gives little benefit immediately.

>
> n.b. I've been following the thread and I am broadly speaking in favour of
> packaging provided it is not the only way updates are provided. Keep
> everyone happy.

Even if everything was packaged only with the current format, it
uses a standard RISC OS compression tool, you can always just
open it up a package with common RISC OS utilities (e.g. SparkPlug)
and drag the application out of it. I suspect any other package
format suggested here will allow the same.

Regards,
Alan

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

#2858

In article <2f85b291-7787-4353-9af7-e13ba42bb6bf@o12g2000vbd.googlegroups.com>,
   Alan <alan_baa@hotmail.com> wrote:
> riscpkg has the following extras that I don't know if are implemented
> by other repositories.

> 1. Allow multiple repositories to be contacted and merge them into a
> single list presenting the latest version for install.

That's how Debian's repository system works.

> This does mean of course you could get everybody deciding they need
> their own repository.

It happens. I have one that holds a couple of packages for Debian based
systems and I know there are others. And of course Ubuntu has Personal
Package Archives (PPAs) which are provided by Canonical, Ubuntu's
developer.

> 2. Any file that is in the package format can be dropped onto the
> iconbar and made available for install so it does not have to have
> come from a repository.

Debian packages can also be installed directly.

Regards,
Frank

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

#2859

On Jan 19, 8:56 pm, Martin Bazley <martin.baz...@blueyonder.co.uk>
wrote:
> The following bytes were arranged on 19 Jan 2012 by Theo Markettos :
>
[snip]
> There's
> a criminal lack of understanding in this thread of the fact that we
> *need* somewhere to start from, no matter how primitive it may be at
> first - and 'starting from' the current libpkg codebase will just
> maintain the current woeful situation (most software unavailable, the
> rest packaged by third parties with all the usual problems with that) in
> perpetuity.

This is your opinion that the current situation is woeful and
packaging by third parties is a bad thing. Not everybody agrees.
I personally believe the libpkg codebase can be built upon.
However this doesn't mean I'm dismissing your ideas or so
stuck on what I've done so far that I won't consider a different
approach.

>
> That would be included pretty much by definition.  The idea is that a
> click on a riscpkg:// URL would add the data contained by the metadata
> file or (if applicable) datestamp on the other end to the local
> database, and then ask you if you want to install the file.  Answering
> no would keep the location on the database for possible future
> installation.

What are your thoughts on how updates will be handled? Will users
need to keep monitoring comp.sys.acorn.announce to see when
an update becomes available? Or will the package manager need
to poll the website of every package that has been installed?
Or something else?

> Well, as my proposals are mostly about finding sensible defaults, it
> follows that the package manager wouldn't be distributed with an
> absolutely blank database file, but one already filled up with as many
> entries as possible, covering all common software and dependencies, and
> hopefully most uncommon ones as well.  (Or with a list/link to list
> suitable for automatic interpreting; see above.)
>
> Getting more would simply be a matter of using Google (as opposed to the
> much more unfriendly package search services which Linux has) to find
> the software's home page, clicking on the presented riscpkg:// URL, and
> selecting "Install now" on the resulting dialogue box.
>
I've been using Google for finding software for a long time, and it
isn't
simple. I don't want to trawl through multiple pages looking
for the correct one. I'd like to easily browse for software and
want a more targeted search for when I can't quite remember the
name of an application.

So in my opinion helping users find software and indirectly exposing
them to what else is about should be put on the list of things we are
trying to achieve.


Regards,
Alan

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

#2862

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

> On Jan 19, 8:56 pm, Martin Bazley <martin.baz...@blueyonder.co.uk>
> wrote:
> > That would be included pretty much by definition.  The idea is that a
> > click on a riscpkg:// URL would add the data contained by the metadata
> > file or (if applicable) datestamp on the other end to the local
> > database, and then ask you if you want to install the file.  Answering
> > no would keep the location on the database for possible future
> > installation.
>
> What are your thoughts on how updates will be handled? Will users
> need to keep monitoring comp.sys.acorn.announce to see when
> an update becomes available? Or will the package manager need
> to poll the website of every package that has been installed?

It would be better implemented as a 'check for updates' button which you
could click (possibly with the option to exclude certain packages),
although a poll at a regular interval would also be possible.

As no repos would be involved, and all the metadata would be kept in
separate files, there would be no need to download the entire index file
every time you checked - instead, you could limit it just to currently
installed software, at the expense of having to make more connections.
The index files on both the official SL RPM repo and major third party
ones are absolutely huge, and can take a matter of minutes to download
by themselves, in spite of the fact that I'm not interested in most of
it.

Since a lot of personal webspace would be involved, limiting bandwidth
use is important.

> > Getting more would simply be a matter of using Google (as opposed to the
> > much more unfriendly package search services which Linux has) to find
> > the software's home page, clicking on the presented riscpkg:// URL, and
> > selecting "Install now" on the resulting dialogue box.
> >
> I've been using Google for finding software for a long time, and it
> isn't simple.

Admittedly I haven't been using package searches for long, but that
definitely isn't simple.

> I don't want to trawl through multiple pages looking for the correct
> one.

Nor do I - but I had to do it several times, for many missing
dependencies, when first trying to get my laptop into a half-decent
state.

And that's on the web-based interfaces.  Don't talk to me about trying
to wrestle with yum on the command line.  Why would anyone put
themselves through that when there's a much more intelligent and usable
twenty-first century search solution available?

> I'd like to easily browse for software and want a more targeted search
> for when I can't quite remember the name of an application.

Every time I've wanted to do that, on RISC OS or Linux, I've used
Google.  Experience has taught me that relying on supposedly
comprehensive repositories to carry a particular package - let alone for
a particular distro - is futile.  I now Google first, and check repos
second, only occasionally finding what I want in one of the second
options.

> So in my opinion helping users find software and indirectly exposing
> them to what else is about should be put on the list of things we are
> trying to achieve.

Both of these can be accomplished with the minimum of effort simply by
distributing an extensive default list with the package manager.

-- 
  __<^>__   "Start off every day with a smile and get it over with."
 / _   _ \  - W.C. Fields
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

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

#2865

On Jan 23, 9:32 pm, Martin Bazley <martin.baz...@blueyonder.co.uk>
wrote:
> The following bytes were arranged on 23 Jan 2012 by Alan :
>
> > On Jan 19, 8:56 pm, Martin Bazley <martin.baz...@blueyonder.co.uk>
> > wrote:

[snip - thanks for the clear explanation of how updates will be
handled]

>
> > > Getting more would simply be a matter of using Google (as opposed to the
> > > much more unfriendly package search services which Linux has) to find
> > > the software's home page, clicking on the presented riscpkg:// URL, and
> > > selecting "Install now" on the resulting dialogue box.
>
> > I've been using Google for finding software for a long time, and it
> > isn't simple.
>
> Admittedly I haven't been using package searches for long, but that
> definitely isn't simple.

If they aren't simple, in whatever way packages are finally shipped,
it
should be one of the things that should be worked on. I believe
searching a targeted list of software helps find it dramatically
quicker
and also makes it easier to browse for related entries. Ideally I
think
that the package distribution system should in some way help
to provide that list.

>
> > I don't want to trawl through multiple pages looking for the correct
> > one.
>
> Nor do I - but I had to do it several times, for many missing
> dependencies, when first trying to get my laptop into a half-decent
> state.

I don't really use Linux systems either, and haven't really used
one as a desktop machine apart from to have a look at it, but
my experience has always been good with the package managers
for setting up the machine in the first place.

The idea here is to get the package catalogue to a state where
you can find most things with it first time and only fall back to
Google rarely.

>
> And that's on the web-based interfaces.  Don't talk to me about trying
> to wrestle with yum on the command line.  Why would anyone put
> themselves through that when there's a much more intelligent and usable
> twenty-first century search solution available?

I agree completely about command lines. Until the modern
linux variants started sporting GUI package managers it was
very difficult to even get started.

>
> > I'd like to easily browse for software and want a more targeted search
> > for when I can't quite remember the name of an application.
>
> Every time I've wanted to do that, on RISC OS or Linux, I've used
> Google.  Experience has taught me that relying on supposedly
> comprehensive repositories to carry a particular package - let alone for
> a particular distro - is futile.  I now Google first, and check repos
> second, only occasionally finding what I want in one of the second
> options.

To me, we should be attempting to turn that around. Unfortunately RISC
OS hasn't got masses of software, so whatever the packaging system,
it should be able to get to a high hit rate for an application on the
packaging system first.

>
> > So in my opinion helping users find software and indirectly exposing
> > them to what else is about should be put on the list of things we are
> > trying to achieve.
>
> Both of these can be accomplished with the minimum of effort simply by
> distributing an extensive default list with the package manager.
>

A program name isn't necessarily enough to identify what
it does. I assume this means there will need to be some
way to get at least a summary for each package.


Regards,
Alan

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

#2883

In comp.sys.acorn.programmer Martin Bazley <martin.bazley@blueyonder.co.uk> wrote:
> And that's on the web-based interfaces.  Don't talk to me about trying
> to wrestle with yum on the command line.  Why would anyone put
> themselves through that when there's a much more intelligent and usable
> twenty-first century search solution available?

TBH on Linux and Android I don't use the package manager/Market for
searching for software either (search terms like 'sound editor').  I Google
then find out the tool is called 'boingthingy', its pros and cons and
whether it'll do what I want.

Then I go to the tool on my device to install 'boingthingy' (at the command
line if I can, using search tools to find out the package name is actually
called 'openboingthingy4' or 'MySoft BoingThingy Free' if it isn't the
obvious).  I sometimes use the web interfaces to
packages.[debian.org|ubuntu.com] or Android Market to find packages, because
they're available everywhere not just in a limited UI on the device.

However, once I know what something is called I just scroll down the package
manager ticking the programs I want (Android is annoying because there's a
series of prompts for every package).  It would be significantly more tedious
to have to chase down web links to find a link to the actual .deb or .apk,
especially if each one is on a different site with a different navigation.

> Both of these can be accomplished with the minimum of effort simply by
> distributing an extensive default list with the package manager.

Will clients regularly download a fresh copy of that list?  If not, it's
going to go stale rapidly.  If so, you need a mechanism for people to change
their entries in it...  and then it's starting to look like a repository by
another name (but a partially indirected one).

Theo

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

#2886

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

> TBH on Linux and Android I don't use the package manager/Market for
> searching for software either (search terms like 'sound editor').  
I Google

To be fair, Android Market's search is really lame. My old phone used 
to show me 'similar',  but the new phone shows "users also looked at" 
and "users also installed". The best way to discover new apps is... 
somewhere else.

Though I suspect this might in part be due to a naff UI and the 
system not scaling to several hundred thousand apps (with a high crap 
quotient). Perhaps not a problem RISC OS is likely to encounter. ;-)


Best wishes,

Rick.

-- 
Best wishes,

Rick.

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

#2753

On 15/01/2012 18:02, Theo Markettos wrote:

> I present the following for comments:

Okey-dokey!


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

While this might seem odd, it does make sense as it then gives the 
flexibility for a manual install *or* a packaged install. Something that 
irked me about rpm files (back circa Y2K) is how hard it was to pull 
stuff out of them if you wanted to look around but not install.


> Packaging information is held in a separate directory, or maybe an
> application.  Let's call it !PackageInstaller for the moment.

It might need to fit into ten characters for compatibility - but 
certainly an application would be good; with a little Absolute inside 
that will fire up the package manager if its variables can be found, or 
otherwise initiate an HTTP fetch to direct the user as to what to do next.


> In other words, a package is simply an author's normal software distro
> but with an additional directory.

A hybrid, I like it.


> Package version

There might be a problem balancing between traditional RISC OS (and, I 
dare say, logical) version numbering x.yy and that bloody horrible Unix 
version numbering, and I quote here the version of NoScript: 2.2.6rc1 
and I've seen worse, like 1.3.2.59381. What the hell?


> Dependencies: Drop other package files it depends on, or enter manually

It might be nifty if it can scan through !Run looking for RMEnsure lines.


> Licence: Select from a list of known licence types, or enter your own
> (non-ideal)

You need to be able to enter your own, not everybody is ready for a free 
licence yet.
I trust one of the known types will be the EUPL v1.1 ;-)


> Copyright: Drop a file with full copyright information, full licence wording
> etc

Shouldn't be necessary with a standard licence, it can be pulled from a 
known location (gnu.org etc).


> Category: roughly what the program does, chosen from a limited list

Plus a place for including tags to aid in selection. The thing I dislike 
most about Ubuntu's system is that it offers a few thousand things, and 
narrowing down the list is a rather clumsy process.


> Security release: should users be discouraged from using older versions due
> to security problems? (see notes on rollback below)

My Firefox nags me to update. I will *when* *I* *am* *ready*.

Ideally, this shouldn't be necessary. Instead, a file called "Changes" 
should list what is different compared to the previous release, and if 
security holes have been fixed - say so.
THIS IS IMPORTANT. There are a couple of Android apps on my phone I've 
NOT updated as the app information gives no list of why this update is 
necessary. Why should I take time to update this? What's new? What's 
been fixed? These are things that should be described. [possibly for 
several past versions for a rapidly-changing project]


> !PackageInstaller.  Optionally it can also upload that Zip to an
> author-defined place (eg their website).

SFTP support? ;-)


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

That's a good idea, get it all done together.


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

Or just "$.Apps.<category>.!AppHere" to avoid it getting too lost. ;-)


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

Very nice suggestion. I wish Android could do this as some updates 
are... defective. I at least have an app that backs up apks in the 
background so I can roll back myself, but official "pick a version" 
support would be nice.

Additionally, the option to "don't notify me about this any more" if, 
say, an application that used to be 26/32 moves to be 32 only; or suchlike.


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

The package manager, or the software being installed?


> 9. Filer plugin for the 'App !FooApp->' menu,

Good idea.


> 10. Core repositories are distributed.  For example repo1.riscpkg.org might
> be hosted by ROOL.  repo2.riscpkg.org by riscos.info.  etc.
[...]

It shouldn't be hard to download the package index from various, and (by 
default) offer only the latest versions.


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

How about an RSS feed from the main package resource, so the package 
manager itself can 'discover' new stuff.



To add some of my own thoughts:

1. Pre- and Post-install execution. There should be an option to run a 
short program before or after installation. This can permit a variety of 
tidy-ups to be performed. I sometimes do this with my own applications 
to autodetect the sort of system in use and provide suitable default 
options, without cluttering up the main executable with such one-off code.

2. The ability to launch the application after install and/or read the 
documentation. Yeah, shamelessly lifted from pretty much every Windows 
installer ever written. ;-)

3. Depending on how much interactivity you would like on the server, it 
might be an idea to offer an option *after* installation where you can 
flag "This package works on my computer" or "This package does not work 
on my computer". The package manager will gather together some basic 
non-unique information and the installed version and upload it to the 
main repo server, so later users can see:
   This software is verified as working on RISC OS 3.7, RISC OS
   4/Select, StrongARM, and however formatted.
   This software may not work on a Beagle.
Perhaps with icons or something instead?
[the "may not work" means the repo received both positive and negative 
feedback]

No, this isn't a ****- "Like, would recommend!" style rating. I've had 
good service from poorly rated apps, and some high rated ones have 
sucked. Instead, this is purely a crowdsource feedback option to notify 
others as to what systems are supported "out of the package" - perhaps 
especially pertinent given the RISC OS 4/5/6 differences, not to mention 
we're still spanning ARM2 to OMAPx...


4. There *ABSOLUTELY* needs to be a way to permit the Package Manager to 
take over pre-existing system resources. While I'm au fait with !Boot, 
if I'm installing something and it needs <x> to run, I don't want to 
screw around moving resources in order for it to be able to install. Let 
it ask if I am willing to let it replace said resource, and then it can 
back up the original and get on with it. This might be best presented as 
a tick-list of things it will replace so you can select *once* and let 
it get on with it without bugging you.

Caveat: Must be able to cope with something ELSE (i.e. SysMerge) doing 
likewise, and not get itself into a panic if the version present is not 
the one it thinks ought to be there.

Caveat: Must be aware that while a resource can be *replaced*, it 
doesn't mean it can *run*. I've had SharedULib with *no* ULib software 
loaded complain about active clients, and thus refuse to do. Needed a 
reboot. Gee, just like Windows. <stir><stir>

Perhaps it might be an idea to try to RMKill existent versions prior to 
autorunning the applications, giving a suitable error if anything fails 
to die? [of course, it *will* check to ensure the version isn't the same]


5. Just a throw-away idea, but some of my software has specific hardware 
dependencies. It might be an idea to prompt for this? Alternatively, the 
pre-install program could try to detect the requires stuff and fault if 
it is not correct. [and thus abort the installation]
Refer to #1.


> (why do developers like distributing things on their homepage?

Because we don't have a universal package system. Because they think 
that it is the place to get help, details, and always the latest 
version? Because they're damned sick of ancient versions floating around?


> How does that fit into packaging?

It doesn't. This is one thing Android and iWhatsit do correctly in that 
you are (normally) locked in to downloading from the Market/AppStore. In 
this way, it encourages developers to place their apps in the correct place.
[at least, on Android, you have the option of otherwise installing from 
elsewhere if you wish]

Okay, it would be a bit draconian to try foisting a policy like that on 
the RISC OS world, however I think there's a point to be made that 
current packaging systems are not as slick as they ought to be, and not 
as widely known as they should be. When RISC OS 5 ships with !NewPackApp 
in !Boot and linked as part of the Apps virtual folder, *then* we'll 
know it's time to package up our own efforts.


> How can we align the motivations so that people will actually want
> to use the system?

I think when the system is adopted by one or both of the RISC OS 
distributions, it'll be a case of "build it and they shall come", for 
instantly you are making the statement "The cool software can all be 
found in here." And anybody that doesn't join in with the programme will 
be left out in the cold for word of mouth, Google searches, and 
"favourite links" on some guy's blog. Really, who wants that when the 
rest are in a nice indexed easy to use catalogue that is simpler than 
online Amazon orders (which are already too damn simple, as my bank card 
will attest!)


> Let the flames commence ;-)

Not at all, it's good to see a reasoned, considered, logical post get 
the ball rolling on something RISC OS needs to get together, especially 
if we're aiming for RaspberryPi and a whole host of potential new users.


I don't know if/how I can help - it looks like I'm going to spend 
_FOREVER_ on bloody night shift, and as such I think I slept most of 
last weekend. :-/ I have the older Castle C compiler, and I hope by late 
Spring (give or take) to have upgraded to the latest ROOL suite. I'm 
okay with C and ARM code, plus BASIC. I like DeskLib, not so keen on the 
Desk: version (too many mucked up names). Only briefly know OSLib, and 
detest RISCOSLib with a real passion. ;-) My socket handling code is 
fairly rudimentary but it works and multitasks nicely. I'm the idiot 
that wrote a teletext program using ANSI characters, but given it 
bit-bashed IIC on the parallel port (both RISC OS *and* DOS [plus x86 
board using ARMEdit]!), I'm quite pleased with it. My current Acorn 
machines are emulated, but I have real hardware around, I just don't use 
it so much as the emulations are just so damn convenient.
Either way, if I can be any use, get in touch!


Best wishes,

Rick.

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

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

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

csiph-web