[gccsdk] FW: Autobuilder packaging progress

Peter Naulls peter at chocky.org
Sun Jan 20 12:04:52 PST 2008

In message <BAY101-W7AEF7448B5C1B36905859F0400 at phx.gbl>
          alan buckley <alan_baa at hotmail.com> wrote:

> My original intention was that the current autobuilt list is basically an
> automatic dump of all the packages created in a run of the autobuilder.
> i.e. The process would be run once every few months somewhere. A
> script would be set off that completely rebuilt everything and
> transferred all the packages to the website.

The problem is that this is far too infrequent.  In lieu of a more
intelligent method, we want builds at least once a week, perhaps more
often for libraries.  Without this, we risk the massive bit rot that was
present in the autobuilder until very recently, when I started a massive
cleanup on the non-games stuff (your game fix ups help too of course).

It's true we don't always want to rebuild an application just because we
can, but it might be best in most cases, especially given our static

> This could cause confusion for the novice user or someone who just
> wants to get something that "just works".

This is the crux of the matter, c.f:

> However it doesn't have to be arduous. If riscos.info could run a
> modified build-website script it would just be a matter of copying
> the package and source to a known location. Even if this is not
> the case I could probably create a program that could create
> a mini differences website locally that could then be copied up.

The problem is that with our very limited resources, offering a "just
works" version is going to always be a best effort.  And in many cases,
the version that works better is likely to be the newer one, not the
older one, since the majority of things we're doing are improvements of
behaviour under RISC OS, rather than new features per se in contrast to
the situation in Linux distributions.

Is it likely we'd want to offer multiple versions of the same package? -
yes, but this is going to be in a minority of cases.  Splitting the
distribution into two parts will just ensure that software from one
doesn't get used or tested.  Better to have one distribution with more
complete user coverage and testing.

In the situation where we want to offer multiple versions of software,
there are a number of options.  The first is simply just to do that -
build an index will multiple versions.  Mostly this isn't used in
Debian, but it works just fine.  I presume RiscPkg handles this.  It's a
bit closer to that used by Cygwin, although not identical.  Another
option is to give the package another name, either using the packaging
aliasing that we have, or perhaps better yet, using the target field
that I outlined in the earlier post on package versioning.


Peter Naulls - peter at chocky.org        | http://www.chocky.org/
RISC OS Community Wiki - add your own content   | http://www.riscos.info/

More information about the gcc mailing list