[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Compiling binaries on package installation



On Tue, Oct 14, 2014 at 09:00:16AM -0400, Yaroslav Halchenko wrote:
> On Tue, 14 Oct 2014, Michael Banck wrote:
> > > > > Or should I point out how to "compile your own", like it is done in the
> > > > > "Building an optimized OpenBLAS packages on your architecture" in the
> > > > > README.Debian file of openblas-base?
> 
> > > > Not sure what's in those files, but I suggest to support
> > > > DEB_BUILD_OPTIONS=custom in your Debian packaging, which would build an
> > > > optimized package for a the user.  That's what the ATLAS package are
> > > > (were?) doing, and if we have enough packages like that, doing the m-a
> > > > like tool as mentioned above would be a matter of knowing which packages
> > > > do support it.
> 
> > > +1 BUT from a user perspective it would have been much more
> > > convenient if there was e.g. 'atlas-custom-installer' package which
> > > would do that automagically at the package installation time.
> 
> > Well, one downside of that would be that you'd need a development
> > environment on every compute node you install it on, no?
> 
> yeap -- but Debian makes it so easy to get any kind of such an
> environment, that for me use of a few more megs of disk space is not
> really a cost to even worth mentioning ;)

Well, and you might have to schedule building the package itself
potentially.  If it is a heavily optimized numerical library (possibly
even brute-forcing the best working set size for cache-access patterns
etc.), it might take a while to build it, as opposed to just install the
final .deb.
 
> > If you bundle a "please rebuild my packages with optimization" script
> > with a local .deb archive, you'd only need to do it once on a frontend
> > box.
> 
> and initially expose those as an apt repository, adjust apt configuration on
> every node...   Then have 2 stage upgrade procedure (in first wave it
> would rebuild locally build beasts, and place them into APT repo, then
> apt-get update and {dist-,}upgrade to pick them up).

Sure, "Einen Tod muss man sterben", as the germans say.

I think it might be a potential GSoC project to come up with a
mostly-integrated solution (at least on the build host).  The
configuration-management side of the APT repos on the client are of
course an issue and cumbersome, but maybe out-of-scope.


Michael


Reply to: