Atlas proposal

[Lucas Nussbaum]

On 18/08/10 at 13:29 +0100, Ian Jackson wrote:
> I think the key thing to remember here is that both writing fast code,
> and its subsequent deployment and performance tuning, are very hard
> problems which are fields of research in their own right.  Our job in
> Debian is not primarily to try to outdo others' work by producing
> programs which are better in all of performance, portability,
> convenience, and impact on other users of the system.  
> 
> Our job is to package up and present the existing work so that our
> users have access to, and their pick of, the best trade-offs currently
> available.  So:
> 
> Josselin Mouette writes ("Re: Atlas proposal"):
> > Just ship two packages: libatlas3gf-base and libatlas3gf-auto, with
> > appropriate Conflicts/Provides just as we have now. And have
> > libatlas3gf-auto depend on all build-dependencies, ship the source, and
> > build itself in its postinst. Gentoo-style.
> 
> I think this is exactly the right thing to do.  It also solves the
> problem correctly in cluster or hpc farm deployments: each node gets
> a version of the library optimised according to its local properties.

The other advantage of this solution is that it can be turned into a
two-steps process, since we are in freeze:
1) upload atlas with only libatlas3gf-base ASAP, so all depending
   packages can build and be pushed to testing
2) later, upload atlas with the addition of libatlas3gf-auto
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |