science-optimisation (Was: About the sense of removing -march=native)
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.
For me the problem is that
a) users tend to ignore README.Debian (I think most of them do not
really know that it exists at all)
b) it might be quite some manual work for several packages that
might need installation on several machines (with similar or
same hardware)
c) creates manual work for every new version
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?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: