[gccsdk] FW: Autobuilder packaging progress
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
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