[Gnewsense-dev] Thoughts/questions on Builder and Dunsink

[Bob Ham]

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/