Re: Trying to get PackMan to install GCC

Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx> wrote:
The really big headscratcher here is devising an alternative for package
repositories, because all my experience of them is that they make
installation vastly more complicated and are very prone to the whims of
fallible humans. I believe the main reason RiscPkg uses repos is that
Graham slavishly copied Debian, rather than sitting down and considering
how a RISC OS packaging system might be expected to work, bearing in
mind anything we can learn from the experiences of other platforms.

The big issue that repositories cope with is consistent dependency tracking.
A repository can be tested consistent (ie all dependencies of all programs
can be met from that repository). A distributed repository has a danger
that some dependencies cannot be met (A v1.2.3 depends on exactly B v4.5.6
and no other but B just got upgraded so v4.5.6 is no longer available. Or
something else needs B v4.5.7 and there's now a conflict and dependency

RISC OS historically hasn't needed this level of fine-grained dependency
control, but RISC OS shared libraries (which are essentially ready, just
need a sensible distribution mechanism) do.

My preferred model would be something similar to RISC OS's present
situation, with just one official download location for every add-on
(which is sometimes enforced in the terms of the licence anyway - some
developers object strongly to anybody else distributing their notionally
free software, even if it's just adding it to a repo). We need
something which doesn't enforce installing everything through the
package manager GUI, so you can double-click on a RISC OS package file
to install it and its dependencies no matter where it came from, but at
the same time it should remain possible (as at present) for non-users of
even the manager backend to open up the container and extract their
software manually.

Yes, I think it's unfortunate that the RiscPkg format has everything buried
in directories: authors should be able to put their application, Readme, etc
at the top level. Additional file(s) can describe what the package manager
should do with them. Possibly that could be a semi-automated app
(fill-in-the-boxes style).

A question this raises is for authors: users who automatically install
software are unlikely to see the Readme that was previously parked at the
top level of you archive: either the package manager needs to present 367
Readmes after installation, or the app needs to do something sensible on
first run (like say WTF it does).

Another issue with a distributed repository is link-rot. Lots of RISC OS
software was once hosted on web pages that are no longer there (at a guess,
over 50%). In a unified repository, you know that all programs are actually
available to download. If that's spread over hundreds of servers, you can
guarantee that some links are broken.

I agree, though, that there's little need for different 'authors' and
'package maintainers'. In the Unix world, a package maintainer's job is to
make the software play nicely with other software in the distro, to enhance
the user experience (so things 'just work'). RISC OS doesn't have the
diversity of distros, so that's more the author's job. However this lack of
indirection does mean there's no option to disagree with the author (eg
author puts out broken new version, there's nobody to say 'we'll stick
with the old one for the moment'. Indeed the package manager will be as if
the older one never existed).

The SysVars and Sprites directories should never have been present in
the first place - they're very symptomatic of trying to shoehorn a Linux
installation paradigm into RISC OS. Users should use the Configure
'Look at' utility after installation, just like they do now.

If so, there should be an option to add installed packages to the 'Look at'
list automatically. Plus an option to deal with command line tools (eg make
an Alias$... variable for them)

Of the current 'Control' file/package index, 'Section' and 'Priority'
should go (in practice, due to the level of personal preference
involved, they make it harder to find applications, not easier),
'Licence' is made redundant by the 'Copyright' file, there should be an

Licence is important because of a need to make decisions automatically. For
example, we might decide not to distribute GPL software without having
source available. We might want to know which apps can be distributed only
without modification. It's much easier to filter if this is a small range
of fields (which Licence currently isn't). We would really rather not have
to read authors' verbiage to make bulk selections.

Priority is useful to know what should be installed to make a minimal
usable system. For example, we need some kind of !Boot. We need
SharedUnixLib. We (on a BeagleBoard) need EtherUSB. And so on.

'Author' field as well as that of the package maintainer, a website URL
should be added, and there needs to be a better dependency model
(consider MBBack, which comes with two helper programs, MBBCtrl and
MBBBoot, which a user might not want to install, but which absolutely
must be uninstalled when MBBack is).

How does the current model not fit that? MBBCtrl depends on MBBack. Remove
MBBack and MBBCtrl is removed too.

Debian has depends/recommends/suggests, so MBBack could 'recommend' MBBCtrl
so that someone installing it knows it's a good idea, but not compulsory, to
install it.

I haven't looked at source packages at all, but they currently seem very
Unix-oriented. I think what I'd like would be a simpler model, where
each package can optionally be associated with a similar package
containing its source code (where the latter has any libraries etc.
listed as dependencies), which can be installed either at the same time
as the binary package, or added to the current installation from the
list of installed packages at a later date.

RISC OS' ability to build downloaded software from source is woeful: too
often it depends on having the same compiler as the author, the same library
setup as their hard disc, and a weird and idiosyncratic build system. It's
far away from just typing 'make' or double clicking a makefile. Partly
because in the past the 'standard' compiler and libraries were commercial,
so everyone's setup was different. So source packages should be encouraged
as a means the software can actually be easily rebuilt, not just a dumping
ground for source code. The GCCSDK autobuilder is currently the best effort
we have, but it's not possible to rebuild such packages on RISC OS.

There's a slight naming issue that source packages might generate more than
one binary package (eg GCC core, C compiler, C++ compiler, Ada compiler,
Fortran compiler, etc etc from the one tree). But I can't see a huge issue
with source packages being in the main repository named *-source.

That's all I can think of for now. Any more ideas, anybody?

The biggest question you haven't addressed is: where do you put things?

Some users will want tight control of where applications go. Others just
want to get on with it: install a fresh machine out of the box, you don't
want to sit there for an hour deciding where every little application you
might never use is going to go (consider all the cruft on Windows' Start
Menus). Do you have a sensible default for 'oh, I don't care, just install
everything', which isn't to pile it all in one big directory?