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

Groups > comp.sys.acorn.programmer > #1367

Re: Fresh packaging ideas

Cross-posted to 2 groups.

Show all headers | View raw

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

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

[snip]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web