Peter Simons
Isaac Jones writes: (snip)
Whenever people mention altering or shipping something with the compilers, red flags go up in my brain.
I didn't mean to emphasize this fact, sorry.
:)
One idea would be to define an XML DTD for describing packages. Maybe work has even been done towards that end already. A conforming document could contain: (snip)
I added those comments to the LibraryInfrastructureNotes page for now. They sound good.
- Packagers for various OSs have a sane way to create packages.
Building binary packages is a whole new world in terms of complexity, and it is a quality assurance nightmare.
Also, for _any_ binary package to be useful, it must be integrated with the packet manager of your Linux/FreeBSD/Apple OS X system. We could provide RPMs for starters, but that's only a fraction of the "market".
Right, I'm not suggesting that we centralize these packages.
IMHO binary packages should be left to the distributors; the Haskell community should rather provide source code.
Yes, the packages will be left to the distributors. However, I think that the library infrastructure should be able to provide some metadata and tools for assisting packagers [1]. To me, this is a killer feature. Proposals for a library infrastructure should deal with the issue of integrating with packaging systems so as not to duplicate work or infrastructure, and so we don't make it harder than it has to be for those packagers. More points if you can make it easier for them.
And more optionally: - A central repository of useful Haskell libraries can be maintained in a way that blends the best of cathedral & bazaar.
Well, I have to admit: For me, the whole process starts _here_. I think we should begin small and let the system evolve.
So to be clear: What happens now (correct me if I'm wrong) is that a consensus is reached on this list about how new libraries should fit into the hierarchy. Then the compiler groups each integrate the packages into their distribution, and when the next release comes around, the end users get the libraries. How would your boost-like distribution system interact with different compilers and their different ways of packaging libraries? Isn't some kind of common build infrastructure like the one I propose still necessary so that they don't have to repackage it?
Again, I refer to boost.org. The project is doing exactly what I proposed, and it has lifted the C++ language to another level. They have practically taken over the language and library development for the new C++ Standard there! So the idea can't be that bad after all.
Some people think that the library infrastructure should look just like FreeBSD, I happen to think it should look more like Python's distutils, someone else might think that Debian has the answer. I'm rather convinced that duplicating any one system will leave us with 1) the flaws of that system and 2) the flaws that Haskell adds to the system by not being a perfect fit. Lets try to look at a lot of different tools and find the best synthesis. peace, isaac [1] ] One issue, for instance, is that a whole plethora of seperate binary packages needs to be provided for various compilers and compiler versions since most of them are not binary compatible (see the previous discussions on packaging stuff for Debian). I think we could help automate the process of generating and maintaining a large set of binary packages.