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
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100818132544.ga24...@xanadu.blop.info
