[gccsdk] FW: Autobuilder packaging progress

alan buckley alan_baa at hotmail.com
Wed Jan 16 09:41:34 GMT 2008


> On Tue, 15 Jan 2008 21:50:03 +0100 John Tytgat wrote:
>
> In message 
> Peter Naulls  wrote:
>
>> I don't recall exactly what John said, but firstly, let's not fragment
>> and spread ourselves too thinly. We don't have hundreds or thousands of
>> developers like Debian to look after different variations of packages
>> not any particular reason to do so. Nor should we provide user
>> confusion by naming things "unstable", with the ensuing explanations
>> that'll be required. All we'll do in the end is ensure that such
>> named software won't get tested.
>
> I agree that the word "unstable" is not reflecting what we mean with it.

I'm quite happy with whatever names seem most appropriate.
>
>> The best anyone can ask or we can provide is a single distribution on
>> a best effort basis. There might be older versions of software in
>> that distribution, but that's ok too.
>
> I'm feeling confident enough about the ELF static based builds but the
> moment we're building with shared libs I think we better get those
> application and libraries in a separate "testing" category until we feel
> we don't have any major issues left.
>
> I would go for "stable" & "testing" category like we also have with the
> GCCSDK releases vs pre-releases.
>
>> As for manual intervention, let's avoid that too, it'll just mean
>> more manual effort later. If we can come up with more generic
>> ways of doing things, even if the initial result takes longer,
>> that'll be better for everyone.
>
> I don't mind seeing a bit of extra effort done upfront if this is going
> to pay off multiple times back later. I like the SCP idea and the package
> website build happening on riscos.info.
>

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.

This automatic process could cause things to break or replace something
with the same version with a slightly different binary. (This is inevitable
when the compiler changes).

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



More information about the gcc mailing list