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

[Sam Geeraerts]

Op Tue, 06 Dec 2016 13:49:32 +0000
schreef Bob Ham <address@hidden>:

> 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".

Patches welcome.

> 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.

There are dependencies between packages, e.g. some package builds query
dpkg-vendor, so calling generation scripts in a specific order is
useful. OTOH, packages are usually not built all at once, so there's
not that much of a chance that something goes wrong. Technically, a
better way to catch this issue is to flag all build-depending packages
when a package gets updated.

Again, patches welcome for you suggestion and mine. :)

> 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?

No.

> Similarly, are there any changes in gNewSense-built packages which
> are not listed in the bazaar history for the package's source
> directory?

No.

> 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?

Eddi convinced me (well, still need to do some more testing) that
merging current Ucclia's repo with Dunsink's repo is doable, so then
there's no need to reimplement Ucclia in Builder.

> 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?

Yes, unless you can convince me that we can have a smooth upgrade path
from Ucclia to a Stretch-derived Dunsink.

> 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?

No. Suggestions for coding style and lint tools/configurations are
welcome. But let's not get forget that style is a means to an end.

> 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.

Rebuilding everything takes a *lot* of resources. It would fix minor
issues, e.g. distro info in Apache. It could be that our patches break
the builds of packages that we don't rebuild. Tracking build-depends
would catch that, but I suspect we rarely ever break a build.