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
