#4256 NORM Never A: Killjoy, stable builds

[Zarro Boogs per Child]

#4256: Killjoy, stable builds
---------------------+------------------------------------------------------
  Reporter:  marco   |       Owner:  kimquirk      
      Type:  defect  |      Status:  new           
  Priority:  normal  |   Milestone:  Never Assigned
 Component:  distro  |     Version:                
Resolution:          |    Keywords:                
  Verified:  0       |  
---------------------+------------------------------------------------------

Comment(by dcbw):

 Adding my comments from an email thread to this bug.

 > Marco is 100% correct.  If you do not build all the packages in the
 > _same_ _stable_ environment, you are simply asking for a big gun to
 > shoot you right in the face, and you deserve it.
 >
 > It's Just That Simple.
 >
 > It doesn't really matter where that environment is, even if you're
 > cross-compiling, just as long as it's a buildroot pulling packages from
 > _one_ consistent repo, using a consistent toolchain, on the same
 > platform, every time.  Anything more than quick testing packages built
 > on personal machines is assured doomage.

 You will often get into the situation where you have installed a
 development package on your machine that is not installed on the XOs or in
 the minimal koji buildroots, and if your package depends on the thing dev
 package you installed, you won't be prompted to add that dev package as a
 BuildRequires.  Then everyone else who doesn't have your exact environment
 cannot build or likely install your package.

 Another situation is for packages like gstreamer that use the configure
 script to dynamically determine the features they will build.  If you have
 installed a library that the configure script recognizes, it will turn
 that feature on and build the package with that dependency.  Then, when
 other people go to install the package, it will either not install, or
 they will get runtime errors about symbols not being found.  You found
 this out when we removed GL from the builds a year ago, and Etoys stopped
 launching.  That's the _exact_ same error that people will encounter.  In
 the case of gstreamer, it would manifest itself in a plugin failing to
 load, and requiring _somebody_ to go track down that error, likely
 spending a few wasted hours going WTF??? before figuring out the problem.

 Different compiler flags on different people's environments make stuff
 completely unreproducible.  Other times, if you build with a different
 compiler version (even a .x.1 off) or a different glibc version or a
 different linker version, then stuff just randomly fails and you cannot
 figure out why.

 Dependencies won't get found.  If, for example, the Collabora guys build a
 package that has a new feature or changes a symbol, you must install that
 package into your private buildroot to be able to use that feature.  You
 quickly start down the chain of unmanagable build dependencies on random
 people's platforms and the matrix starts scaling out horribly.

 There was a time years and years ago when Red Hat did not build packages
 in a build system.  RH quickly figured out why this was a bad idea.
 Jonathan Blandford (Desktop Team Manager) says, simply: "Shit didn't work,
 and people couldn't figure out why."  That's just what happens.

 Seriously.  Just Don't Do This.  Have _one_ buildsystem that everyone
 pushes packages through to ensure consistency of the generated code,
 consistency of the dependency set, consistency of the runtime environment,
 and consistency of the product overall.  I cannot stress this enough.

-- 
Ticket URL: <https://dev.laptop.org/ticket/4256#comment:10>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system