> 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 needed. Regards, Alan _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
