On Thu, 2017-02-09 at 16:13 +0100, Michael Banck wrote: > Hi, > > On Thu, Feb 09, 2017 at 11:47:59AM +0100, Andreas Tille wrote: > > Hi Julien, > > > > On Wed, Feb 08, 2017 at 06:15:37PM +0100, Julien Puydt wrote: > > > > I wonder whether we could invent some mechanism that is rebuilding a > > > > package in postinst and installs the result on the machine instead of a > > > > pre-build binary. Or we could provide some toolset which enables > > > > scientists to download a set of source packages and build these after > > > > re-activating -march=native and move the results in a local repository > > > > which just needs to be added to sources.list. > > > > > > > > Do you consider this as feasible ideas? > > > > > > The src:atlas package does something like this : > > > - the Debian servers ship a generic package ; > > > - the source package has a special build target for a more optimized > > > package, which you can then install. > > > > I've read README.Debian "Building Optimized Atlas Packages on your ARCH" > > and think this is pointing very much in the same direction of my second > > rough idea. For packages that could profit from some optimisation for > > local machines we could provide a custom target in debian/rules. While > > I did not yet made up my mind whether it is a good idea to build inside > > the local environment instead of a pbuilder chroot, this is a detail > > that could be discussed later. > > I think I read the ATLAS README.Debian and found it a bit more > convoluted than necessary; in particular, I think it creates binary > packages with different names to ones in the official archive (sorry > can't check at the moment as I am on crappy dialup)? Probably just > bumping the binary package version like we do for backports or binNMUs > would be enough. > > A good start would be to both support DEB_BUILD_OPTIONS=custom for > generic performance-oriented rebuidls and > DEB_CFLAGS_MAINT_APPEND=-march=native for for the -march=native thing. > > Then again, just testing whether it actually makes a difference for > end-user applications would be useful as well. > > Michael
I was about to suggest something similar using build profiles [1]. They sound tailored for this sort of alternative build strategies. [1] https://wiki.debian.org/BuildProfileSpec Ghis
