[Raspbian-devel] On compiler defaults and derivatives.

[peter green]

There are derivatives of debian that change compiler defaults (for 
example minimum CPU requirements). Two such derivatives are raspbian and 
ubuntu. First lets look at how those derivatives currently handle things.

Ubuntu

The ubuntu approach is to include the ubuntu specific stuff in the 
debian packaging then activate it either based on release codenames or 
distribution names. This has some advantages and disadvantages

Pros:
* Compiler version numbers can in principle stay the same (though in 
pratice they rarely are) allowing multiarch compatibility.
* Presumablly fairly easy to maintain.

Cons:
* Mistakes in the conditionals can result in settings intended for 
ubuntu being accidently used on debian (for example I discovered a case 
in the wheezy cycle where building gcc on a system that identified 
itself as wheezy resulted in the use of some settings intended for ubuntu).
* Code that is specific to a derivative ends up in debian.
* IMO not scalable to larger numbers of derivatives.

Raspbian

The raspbian approach is to simply patch the compiler source packages

Pros:

* No derivative specific settings end up in debian.
* Therefore deriviative specific settings can't accidently end up being 
used in debian because someone made a typo
* Scalable to large number of derivatives (since what one derivative 
does doesn't affect another deriviative)

Cons:
* There are a LOT of compiler source packages in debian, it's easy to 
miss some
* Manual effort is required whenever one of those compiler source 
packages changes
* Inevitable version skew makes it difficult to do a multiarch 
combination of say debian armel and raspbian armhf.

Proposed new soloution

* Centralise the compiler defaults into a new source package called 
compiler-defaults.
* Each compiler source package would reference the defaults in this package.
* Each derivative would have their own version of this package with the 
defaults they desire.

Pros:
* No derivative specific settings end up in debian.
* Therefore deriviative specific settings can't accidently end up being 
used in debian because someone made a mistake in the rules
* Compiler package versions can remain the same between debian and 
derivatives allowing multiarch combinations
* New versions of compilers can enter the derivative without manual 
intervention

Cons:
* Someone would have to actually implement it (I may consider looking 
into this myself but I can't promise timescales)

What do other people think?