Re: SmartMenu - was: VRPC on a USB pen

The following bytes were arranged on 13 Nov 2011 by Steve Fryatt :

On 13 Nov, Martin Bazley wrote in message
<3ec17c3152.martin@xxxxxxxxxxxxxxxx>:

If a developer is incapable of following the existing, defined procedures
for loading modules, what on earth makes people think they would magically
follow the defined procedures for installing them?

We're talking about a third-party module that, IIRC, was distributed either
with the software that originally used it or in a zip file with no wrapping
or instruction. What /were/ other developers supposed to do with it?

They could follow the *existing*, *defined* *procedures* for installing
modules, which is that, unless they are really closely tied into the
application they came with (which WimpSWIVe is not) and thus useless to
any other program which might wish to load them, they are distributed
inside a template !System directory with just enough of the directory
structure in place to determine the module's location in the real thing.
This dummy !System is then dropped onto !SysMerge, which will examine
its contents, ignore any ones which are older than versions already
present, make backups of any which are upgrades on pre-existing
versions, and copy files into the main !System directory as appropriate.

Why am I describing this process to you? Is it now clear what I meant
by "contriving to misunderstand"?

Look no further than NetSurf for an example of exactly how it's supposed
to work. The Iconv, Tinct, SharedULib and URI modules could quite
easily have been force-loaded from inside the !NetSurf application, as
apparently a number of applications relying on WimpSWIVe have done, but
there are very good reasons why they aren't.

Even RiscPkg enforces this convention - all system resources must be
distributed inside a subdirectory called 'System' containing a partial,
dummy hierarchy leading to modules in their conventional places.
Converting this to a format parseable by SysMerge (or it might work
anyway - I haven't actually tried) is a matter of adding a leading "!"
to the name "System", and this is only because of a bad decision taken
when writing the policy manual. (Another example, incidentally, of
RiscPkg's intervention in the process being less than necessary.)

Others have pointed out that the RiscPkg application itself is a bit
braindead about this whole business, both loading and installing sides,
which serves perfectly to illustrate my original point about how, even
in applications distributed via package systems which are supposed to
eliminate, among others, precisely this problem, there is still oodles
of scope for the creators of distributed software to get it hopelessly
wrong. Packaging will not solve, and demonstrably has not solved, this
problem.

They could either hide it inside their own application and so avoid
having to get the user to install it, or they could present the user
with a two-stage installation process and wordy instructions.

I quote once again from the NetSurf archive:

---8<------8<------8<------8<------8<------8<------8<------8<---
Installation
------------

Installation is a three step process:

1. Use the Boot Merge facility provided by Configure to merge
the supplied !Boot directory with the one on your system.

If there is no !Boot merge facility on your system, simply
drag the supplied !Boot over your existing boot structure.

2. Use the System Merge facility provided by Configure to merge
the supplied !System directory with the one on your system.

3. Drag the !NetSurf application directory to a place on your
hard disc.
--->8------>8------>8------>8------>8------>8------>8------>8---

This is as *complicated* as installation instructions get. In the
theoretical WimpSWIVe example we are considering, step 1 is not
necessary, and I'd personally say that the second paragraph of step 1 is
not necessary, full stop. Given that it is standard procedure for
absolutely everything in RISC OS, most users will not need to be
informed of step 3 either.

More complicated procedures for 'premium' free software may exist -
DigitalCD and StrongED being two particularly bad examples - but, by and
large, they are rare, and try to smooth over the difficult bits when
they do arise. DigitalCD, for example, automatically upgrades its skins
and plugins when first run, although I think there's a gap in the market
for a tool to automate its tiresome and tedious exhortation to 'merge
your MimeMap file with the one supplied'!

Were WimpSWIVe to be packaged, I'd guess that it would be set to install
into a central location

You mean, like, !System?

and any clients, when packaged, would be updated accordingly. And we
would have the best of both worlds: a one-step installation, while
WimpSWIVe and the client are treated as separate entities with a
dependency.

Indeed. I'm not denying the attractiveness of such a state of affairs,
nor am I claiming that RISC OS's current system isn't imperfect in ways
that a package manager might theoretically, technically, have the
capability to rectify. But for as long as computers remain the
grudging, efficient servants of emotional, unreliable humans, your
scenario will never ever ever happen, not if a successor a thousand
times improved upon RiscPkg were to emerge. Until such time as Skynet
can rise up and enslave us all, the human factor will continue finding
new and ingenious ways to bollocks up any distribution standard you care
to dream up.

All the package management in the world won't stop humans being humans.
It's nothing like the magic bullet its proponents claim it to be. My
experiences with RPMs led me to uncover this inconvenient fact.

My experience with Debian's packaging system has been pretty positive, at
least once I'd realised that there were benefits for *me* in working with it
and not fighting it at every stage.

Speak for yourself. At most stages I haven't had any choice. Do you
have any idea how outdated Scientific Linux's official repositories are?
More than once I've been caught out by software demanding dependencies
which are either absent or newer than the latest official version
available for any RHEL clone anywhere. The situation isn't helped by
infighting among the various third-party repository maintainers, each of
whom provide a very slightly different subset of all theoretically
compatible software, which is apparently enough to cause critical
incompatibilities if you enable the wrong combination at the same time,
and sometimes even none of them have it.

Let me quote just one example, from just this very morning. Today I
started a Haskell module in my university course, and unsurprisingly one
of the lecturer's first assignments was to go away and install the
Haskell compiler and associated tools (collectively referred to on
haskell.org as the 'platform' package).

Easier said than done! Needless to say, it was neither pre-installed
nor available on any compatible third-party repositories. Apparently
(after hours of Googling, I determined I'm by no means the first person
to suffer from these problems) Haskell's flat refusal to support RHEL
of any stripe, or vice versa, or both, is the stuff of legend. If your
system isn't listed on the list of packages, you are instead forced to
build it from source.

A large percentage of the 'platform' bundle was, naturally, written in
Haskell (standard libraries and that sort of thing), which meant you
needed GHC, the Haskell compiler, installed before you could build the
'platform' bundle. Where was the recommended place to download GHC? Oh,
yes... the 'platform' bundle. Well, the packages, at any rate,
presumably via some of these famous dependencies... the same could not
be said for the 'source' zip.

So the very first thing I had to do was to download the compiler
separately (thankfully I didn't have to build *that* from source), in
what was supposed to be a 'one-step' process, purely to bootstrap the
rest of the archive. This meant I had to first download, and manually
install via an old-school terminal window and faffing about in /usr/lib
(oh, how I miss those drags and drops of single directories - even RISC
OS GCC manages it!), the compiler, before I could even think about
downloading the 'platform' source zip and attempting to compile, and
subsequently install, that.

I did eventually manage to get things up to this stage, and immediately
ran up against another hurdle. It seemed that the compiler wouldn't
work, because I didn't have the libgmp shared library installed. Off I
went to the GNOME package installer again, always my first port of call
in such circumstances, although usually with diminishing hope and
expectations each time. Much to my surprise, it turned up a perfect
match, and what's more swore blind that it was already installed.

By this point the air in between my vision and my laptop screen had
turned such a deep shade of blue I could squint and pretend I was
running Windows instead. After yet more Googling, I eventually found
the answer by accident, after following a piece of advice (on an
Ubuntu-centric blog) which looked harmless enough and potentially
vaguely relevant to my issue, which as it turned out was exactly the
same problem the author was suffering from. It appears there has been a
spate of libgmp packages which create the libgmp.so.3 symlink, but
neglect to create the libgmp.so symlink which GCC rather firmly insists
upon being present. This, I am pretty sure, is a bug. All I know is
that I created such a symlink and everything magically worked (bar a
second, more successful, trip to the SL repository to install another
dependency, in this case freeglut).

And all this was *before* I had even got a whiff of the 'platform'
goodies at all. I subsequently had to repeat the process, this time
with GHC installed, in order to compile everything else. This took so
long I could have installed an (imaginary) purpose-built platform
package over a dial-up connection in less time.

I still haven't completed the last step, which is to update lots and
lots of what I can only assume are platform-independent Haskell-designed
packages.

You might argue that all of my problems (except possibly the libgmp one)
were the product precisely of my *not* having installed from a one-stage
package, rather than stepping through all the stages they eliminate
(most of which, I would like once again to remind you, would not occur
on RISC OS). To say this is to miss the point entirely. My woes are a
*direct consequence* of one of the fatal flaws of the package system -
namely, that it makes it a hell of a lot easier to fail to support a
certain system.

This is by no means the first problem I have had with packages simply
not existing, and it won't be the last. The amount of software
theoretically compatible with one's computer is severely constrained by
how many or few programs have been laboriously packaged up for your
distro (in the process duplicating much effort expended on every other
distro simultaneously), and further constrained by the presence of
packages which are theoretically available for one's distro, but list as
dependencies packages or version numbers which are not (usually, in the
case of version numbers, entirely spuriously, as in the case of the RISC
OS applications which *RMEnsure the version of the Toolbox modules which
the author happened to have on their computer, regardless of actual
compatibility, or whether such a number even exists on the other fork).

All of these problems stem solely from the decision to standardise
software updates through a package system. I think I mentioned in my
last post which was as long as this one that if there was one thing
which had finally convinced me to change my mind about RiscPkg from
merely ambivalent to firmly opposed, it was my experience of fighting -
yes, I do believe that is the appropriate word - with a mature packager
with widespread community support. RiscPkg is only barely hanging
together because the RISC OS community is simply so small (only *one*
somewhat-incompatible-in-obscure-ways schism! Imagine!) and developers
so few that the cats can be relatively easily herded. I repeat:
packaging will never solve more problems than it causes. On a system
like RISC OS, where unaided installations are comparatively trivial,
we're better off without.

--
__<^>__ === 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 ===================
.

Relevant Pages

  • Errors applying kernel patch 118833-36
    ... install of Solaris 10 11/06. ... However, once the package list is done, I see a worrisome message: ... Below is the complete console output of the patch run. ... Changes for package SUNWnfsskr will not be applied to the system. ...
    (SunManagers)
  • Re: Stronghelp - can I change location set by Packman?
    ... it was needed to install a package though. ... RISC OS desktop. ... Simpler for the newbies arriving from Linux, ...
    (comp.sys.acorn.apps)
  • Re: Package and Deployment Questions
    ... > on your target, and the specific platform. ... > VB Runtime out of the install is a good idea. ... > package, because the components actually included are the ones in the ... > The MDAC is different in that there are so many different versions. ...
    (microsoft.public.vb.general.discussion)
  • Re: Stronghelp - can I change location set by Packman?
    ... piles of applications causes lots of random file reads, ... third party installers such as, say, a package manager, but it all got ... applications *do* install things into Choices. ... I have nothing against an app in Choices - it's ...
    (comp.sys.acorn.apps)
  • Re: A little help please!
    ... This so far was the best map to getting DVD media working I am going to ... Also I have the latest libdvdcss2 and libdvdcss2-dev installed. ... sudo aptitude install totem-xine ... Click either free or non-free depending on where the package you ...
    (Ubuntu)