Re: science-optimisation (Was: About the sense of removing -march=native)
On Fri, 2017-02-10 at 11:12 +0100, Sébastien Villemot wrote:
> Le jeudi 09 février 2017 à 11:47 +0100, Andreas Tille a écrit :
>
> > I could imagine to include inside the Debian Science metapackage
> > framework a package say science-optimisation. This contains a list
> > (OPTPKG) of packages that could profit from local optimisation. At
> > install time it could give some information via debconf about the
> > possible optimisation means which could be triggered in a (postinst??)
> > script. Package science-optimisation Depends: devscripts.
> >
> > The script does the following:
> >
> > - check what packages of OPTPKG list are installed
> > - apt-get source <installed pkgs that are in OPTPKG>
> > - apt-get build-dep <installed pkgs that are in OPTPKG>
> > - iterate through unpackaged sources and do
> > fakeroot debian/rules custom
> > (to clarify: will build process it self depend from libs that
> > need to be optimized first)
> > - reprepro *amd64.changes
> > (some default configuration should be inside
> > /etc/science-optimisation/reprepro )
> > - tell user to add reprepro location to sources.list and to
> > apt-get update; apt-get upgrade
> > - new package versions of packages in OPTPKG need to trigger
> > re-running the script
> >
> > IMHO this is a feasable way to take some workload from admins shoulders
> > (or might damins even aware that there actually is some work to do at
> > all) and by doing so could increase the acceptance of Debian among
> > scientists (who otherwise might prefer archlinux or other distributions
> > that are building on the target machine).
> >
> > Do you think that is a sensible idea?
>
> The idea looks quite interesting to me (though we probably need more
> data on the effects of such performance-tuning before embarking into
> such an effort).
>
> If this gets implemented, we need to define an interface for creating
> the optimized builds. For src:atlas and src:openblas the interface is
> currently to run "fakeroot debian/rules custom" (after having installed
> devscripts in addition to the build-deps, because dch is used to append
> a suffix to the version number).
>
> Michael Banck convinced me that using DEB_BUILD_OPTIONS=custom would be
> a nicer interface, and I therefore opened #854781 and #854784.
>
> Another option would be to use build-profiles, as suggested by Ghislain
> Vaillant. This also seems to be a good fit. Some investigation is needed
> though, especially because apparently that build-profiles are meant to
> be compatible with reproducible builds (while by definition
> optimized-build are not reproducible across machines).
They are meant to for the ones that are standardised, i.e. nodoc,
nocheck, nopython...
However, since the tentative "custom" profile will not be standard
across the archive anyway, neither the buildds nor the reproducibility
testers should be using it.
Ghis
Reply to: