[gccsdk] FW: Autobuilder packaging progress

alan buckley alan_baa at hotmail.com
Tue Jan 15 01:28:25 PST 2008

> I wrote:
>> On Sun, 13 Jan 2008 21:00:36 -0800 Peter Naulls wrote:


>> In message
>> alan buckley wrote:
>> I'm not sure of the precise mechanics (but I'll figure it out very
>> shortly), but I expect it'll be something along the lines of a package
>> being SCPed to a certain location (by you, John or myself as the main
>> protangonists here, and the only ones with access) and having the index
>> automatically regenerated on the hosting machine every hour or so.
> I don't think the index needs to be regenerate so often. Thinking about
> what you've said here, would it be possible for us to SCP the package and
> its source to a staging area where a process could check for additions
> and then schedule an early morning rebuild of the website and package
> index. All the rebuild would need to do is copy the changes to the
> autobuilder_packages directory on this machine and run the build-website
> script.

Sorry I think I've got carried away here overcomplicating things. The
original idea was that the autobuilder would just run automatically once
every few months and create the website/package index as the last
thing it did.

I notice Peter has added a statistics script, we may want to publish its
results as well.

Because of the versioning this means that the packages could change
slightly if the compiler changes, but as long as users try to update
the autobuilt list in the package manager if they get a problem it
should work.

I think we should use John Tygat's suggestion of providing some other
distributions at riscos.info. I'm going to look into at least adding an
unstable distribution initially. This will be built by hand copying specific
versions from the autobuilt distribution and then generating it's
webpages and package index.

This distribution will be what most users would then be directed to
because we would ensure that specific package versions have been
at least tried before being copied there. We would also ensure that
a package has a new version before it can replace a package already
on the unstable list.

Telly addicts unite!

More information about the gcc mailing list