[gccsdk] FW: Autobuilder packaging progress

alan buckley alan_baa at hotmail.com
Mon Jan 21 08:59:29 PST 2008

> On Sun, 20 Jan 2008 12:04:52 -0800 Peter Naulls wrote:
> In message 
> alan buckley  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).

OK, the once every few months idea was because I wasn't expecting
things to change that often. More frequent builds is fine by me.

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

My only problem is with versioning. It would be nice if we had someway
of automatically increasing the version number if the binary changed in
some way. However I guess the only practical approach will be to 
try and increase the AB_ROVERSION version whenever anything is
changed in the package once it has got onto the website.

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

OK, I accept the limited resources argument. I think we can put off the
idea of a more stable package until later then. It may be that it becomes
necessary if the autobuilt version breaks too often, but hopefully that
won't be the case.

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

RiscPkg doesn't handle multiple versions as far as I can see. However
renaming the packages would work. Hopefully this won't really be


Get Hotmail on your mobile, text MSN to 63463!

More information about the gcc mailing list