On compiler defaults and derivatives.
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?
Reply to: