Hi all, I've had a look at Builder now and I thought it would be worth noting some thoughts and questions:
0. A lot of the environment variables used as configuration options are basically static data that describe possibilities in the structure of the upstream archive. I think a better way for the scripts to work would be to have a set of static data for different upstreams and generalised scripts configured with a single option. For example, a directory "upstreams/" containing "hardy.conf", "wheezy.conf", "stretch.conf", etc. and a configuration option like "UPSTREAM=stretch". 1. Calls to the package-specific generation scripts are hard-coded. Rather than having a long list of lines of, for example[0] "ensure_updated blender blender $RELEASE$distro_release ./gen-blender $BLENDER_VERSION" I think it would be better to have the package-specific generation scripts detected automatically, along with any upstream- and version-specific tweaks. For example, a directory "package-scripts/" containing files in sub-directories like "blender/gen.sh", "blender/upstreams/jessie/gen.sh" and possibly some common code to automatically execute specific tweak scripts according to comparisons of the package version or other variables. 2. There is a directory in bazaar named "packages-ucclia"[1]. Presumably this contains all of the packages for Ucclia. Are there any gNewSense-built packages in Ucclia whose sources are not present in that directory? Similarly, are there any changes in gNewSense-built packages which are not listed in the bazaar history for the package's source directory? 3. Sam, previously you stated that you would like to target Ucclia (based on Wheezy) with new Builder scripts before moving on to Dunsink. However, there are changes in the builder_lordeddi branch in bazaar which refer to Debian Jessie[2] which would obviously not be targetting Ucclia. Has there been a change in the intention to target Ucclia first? 4. Also, to me it makes more sense to target Stretch rather than Jessie for Dunsink. Stretch is already in "transition freeze" and will be fully frozen this coming February. I can't imagine Builder being in a place to create Ucclia, let alone Dunsink by then. Meanwhile, Jessie is getting on for two years old. The freeze period for Stretch would provide an appropriate period for developing Dunsink. Having a Stretch-derived Dunsink released in tandem with Stretch, or as close to as possible, would really be a boon to (1) gNewSense's usefulness and appeal, and (2) the power of the statement made by having a free version of Stretch. Sam, is it your intention for Dunsink to be derived from Jessie? 5. In general, there seems to be quite a bit of technical debt. I've noted a lot of copy-and-pasting, different indentation schemes within the same script and even the same function, and so on. There's a fair amount of cleaning up needed. Is there an explicit coding style noted anywhere? 6. I discovered that Builder copies and makes use of Debian's .deb files without recompilation. I was under the impression that all packages in the archive would be recompiled. In fact I was under the impression that recompilation was expected of all Debian derivatives but I looked at Debian's guidelines and they state "for those derivatives that re-use Debian binary packages"[3] so plainly they're OK with it. I believe this[4] article gave me the wrong impression. I note this for anybody following who may also be under the wrong impression. Regards, Bob [0] http://bzr.savannah.gnu.org/lh/gnewsense/builder/annotate/head:/do-update#L337 [1] http://bzr.savannah.gnu.org/lh/gnewsense/packages-ucclia/ [2] http://bzr.savannah.gnu.org/lh/gnewsense/builder_lordeddi/revision/518 [3] https://wiki.debian.org/Derivatives/Guidelines#Repositories [4] https://lwn.net/Articles/676664/ _______________________________________________ gNewSense-dev mailing list gNewSense-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/gnewsense-dev