Re: Library Infrastructure Proposal & Home Page
Sorry I haven't gotten around to replying to everyone's comments. I've been shifting apartments :) "Simon Marlow" <[EMAIL PROTECTED]> writes: > I think the proposal is great. Thanks! > It might be worth saying earlier on that the library infrastructure is > expected to be a layer underneath the platform's native package support > (if such support exists). Good point. Thanks. > FreeBSD's ports is both a source and binary package system. A FreeBSD > system functions perfectly well using only binary packages. I see. Can you give me a light summary of what a binary package for BSD looks like? Do people distribute binary packages on their web sites? > FreeBSD (in source or binary mode), and Gentoo, have no support for > recompiling packages when something they depend on has changed. This is > the biggest failing of these systems IMHO. The 3rd paragraph of 2.1 > therefore isn't correct - I think I made it clear in the next paragraph that this is still a problem in FreeBSD, but I'm only suggesting that the end user actually has a reasonable _solution_ for a source distribution. In a binary distribution, the user either has to download the source (package) and recompile themselves, or wait for the maintainer to do it. However, your point about FreeBSD having binary packages may make all of that false. > there's still a big problem for source-based distributions. However, > this is not *our* problem, it's theirs - when a dependency is > updated, everything that depends on it should be recompiled. In fact, I was recently thinking that binary distributions like Debian should have some support for a recompilation: a package should be able to declare that it has this special "recompile" dependency on ghc / nhc / xemacs / gnuEmacs, and when a new version of the compiler is uploaded to the autobuilders, they should go out and recompile all the packages. Instead, Lisp, Elisp, and Haskell all have to roll their own solutions for roughly the same problem. > ./Setup.lhs bdist: wouldn't it be better to create a source RPM than a > binary RPM? That's a good point. > Once you have a source RPM the RPM tools can be used to build a > binary RPM. Similarly for FreeBSD and Gentoo - I'd expect Setup.lhs > to produce a port skeleton/ebuild for me, not a binary package. That is what the prototype does for Debian; it creates the skeleton for the user to edit and build the binary distribution from, except that it does actually go ahead and build the binary distribution, for better or worse. > The PackageConfig file: I'd leave out 'provides' and 'isDefault' unless > we have a convincing example which needs them. Actually, I consider the Haskell Implementations themselves to be the best example: we want a way to say that libraries depend on having a Haskell98 (or Haskell04 ;) ) Implementation installed, and we want to be able to track the default Haskell Implementation. Perhaps this should be built into the system, but I think it has more general applicability. For instance, if we had that common GUI API that was discussed at ICFP, and there were several implementations of it (one for Windows, one for Gnome, one for TCL or whatever), then a package could depend on having "something that implements the GUI API", rather than a particular package. > Possibly add: 'haddock_html_root :: String' and 'haddock_interface > :: String' for documentation. I definitely like that idea. > I'm thinking about removing 'extra_ghc_opts' - it's highly dodgy > when combined with 'auto'. I'll remove it from the proposal for now, and I'm going to add this text: I propose that implementation-specific fields be prepended with the implementation name: ghc_interpreter_flags, hugs_interpreter_flags, etc. > I agree with Ross's comments about data vs. code. Let's abstract as > much as possible as data. What did you think about my points in the followup post. I definitely agree that we want to leverage this data, but there are a variety of ways to do it! peace, isaac ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Library Infrastructure Proposal & Home Page
* Simon Marlow <[EMAIL PROTECTED]> [2003-09-26 12:08 +0100]:
> FreeBSD (in source or binary mode), and Gentoo, have no support for
> recompiling packages when something they depend on has changed. This is
> the biggest failing of these systems IMHO. The 3rd paragraph of 2.1
> therefore isn't correct - there's still a big problem for source-based
> distributions. However, this is not *our* problem, it's theirs - when a
> dependency is updated, everything that depends on it should be
> recompiled.
This is true for the FreeBSD base system, but it is recommended nowadays
to use sysutils/portupgrade for managing ports. With portupgrade you can
simply do `portupgrade -rf changed_pkg` to recompile all packages
depending on the changed one. The only reason why portupgrade is not
part of the base system is that it is written in ruby and we are not
willing to include ruby in the base.
BTW, as David Roundy pointed out already, the haskell config file should
be in /usr/local/etc for FreeBSD please. Or better, in $LOCALBASE/etc,
where LOCALBASE is a variable pointing to /usr/local by default.
Regards,
Olli
--
Oliver Braun -- obraun @ { unsane.org | FreeBSD.org | haskell.org }
pgp0.pgp
Description: PGP signature
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: Library Infrastructure Proposal & Home Page
I think the proposal is great. Here's some random comments: It might be worth saying earlier on that the library infrastructure is expected to be a layer underneath the platform's native package support (if such support exists). For example, I've never used Python's Distutils, but I have a bunch of Python packages on my system that were installed using the native package system on top of Distutils (I presume). FreeBSD's ports is both a source and binary package system. A FreeBSD system functions perfectly well using only binary packages. To a certain extent Gentoo is the same, although they place far less emphasis on binary packages. FreeBSD (in source or binary mode), and Gentoo, have no support for recompiling packages when something they depend on has changed. This is the biggest failing of these systems IMHO. The 3rd paragraph of 2.1 therefore isn't correct - there's still a big problem for source-based distributions. However, this is not *our* problem, it's theirs - when a dependency is updated, everything that depends on it should be recompiled. ./Setup.lhs bdist: wouldn't it be better to create a source RPM than a binary RPM? Once you have a source RPM the RPM tools can be used to build a binary RPM. Similarly for FreeBSD and Gentoo - I'd expect Setup.lhs to produce a port skeleton/ebuild for me, not a binary package. The PackageConfig file: I'd leave out 'provides' and 'isDefault' unless we have a convincing example which needs them. Possibly add: 'haddock_html_root :: String' and 'haddock_interface :: String' for documentation. I'm thinking about removing 'extra_ghc_opts' - it's highly dodgy when combined with 'auto'. I agree with Ross's comments about data vs. code. Let's abstract as much as possible as data. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Library Infrastructure Proposal & Home Page
Followups to [EMAIL PROTECTED] please. Greetings, After many rounds of email and discussion, some wiki work, and discussion at the HIM, I've finally put together a proposal for the Library Infrastructure Project. I've inserted the introduction below. The draft proposal itself is available in a variety of formats. I've also started a web page for the project under the haskell.org site: http://www.haskell.org/libraryInfrastructure/ Please let me know if there's anything that needs to be added, if anything is confusing, etc. Comments and questions are welcome by email or on the [EMAIL PROTECTED] mailing list. peace, isaac ps. I expect to be moving a lot of stuff off of the wiki page since it is duplicated here. Library Infrastructure Project Proposal The Library Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. The Haskell Implementations[1] come included with a good set of standard libraries, but this set is constantly growing and is maintained centrally. This model does not scale up well, and as Haskell grows in acceptance, the quality and quantity of available libraries is becoming a major issue. There are a wide variety of Haskell Implementations (both compilers and interpreters), each of which target a variety of hardware architectures and operating systems. There are also a number of different groups and individuals providing libraries, and these libraries depend upon each other and they depend upon external systems such as Java or GTK. It can be very difficult for an end user to manage these dependencies and build all the necessary software at the correct version numbers on their platform: there is currently no generic build system to abstract away differences between Haskell Implementations and operating systems [2]. The Library Infrastructure Project seeks to provide some relief to this situation by building tools to assist developers, end users, and operating system distributers. This is a draft proposal. If you have comments, please email Isaac Jones. The latest version of this document should be available in a variety of formats from the Library Infrastructure Project home page. _ Table of Contents 1. High-Level Overview 2. Issues Facing Developers 2.1. Issues Facing Packagers 2.2. Why We Should Solve This 3. A Solution for Haskell in Haskell 3.1. The Module Design 3.2. But Why Should We Use Haskell? 3.3. Setup.lhs Command-Line Interface 3.4. An Example Setup.lhs Script 4. Distribution Module 4.1. Distribution.Build 4.2. Distribution.Install 4.3. Distribution.Package 4.3.1. PackageConfig Data Structure 4.4. haskell-config Command-line interface 4.5. haskell-pkg? 4.6. Distribution.Config 5. Use Cases 6. Means of Distribution and Layered Tools 7. Development Plan A. Related Systems A.1. Debian A.2. Python Distutils A.3. CPAN and Boost A.4. FreeBSD's Ports System A.5. The XEmacs Packaging System A.6. Make-Based Systems A.7. hmake 1. High-Level Overview On a high level, we say that we want the system to help the user to install packages (whether they be libraries or applications) and their dependencies. To accomplish this, we propose a system similar to Python's Distutils (Section A.2) where each Haskell tool is distributed with a script (Section 3.4) which has a standard command-line interface. This script will provide a familiar user interface (Section 3.3) for compiling, installing, and removing packages and their dependencies. For instance, to install the HUnit package, the user might download the source code from the web site, change into the HUnit directory, and type ./Setup.lhs install default, which would build and install the HUnit package for the default compiler. Similarly, he might type ./Setup.lhs install nhc to install the package for NHC. Other tasks might be necessary to make the package known to the system, such as registering it with the Haskell Implementation of interest (Section 4.3). Such tasks would also be performed by this Setup program. FULL TEXT AT: http://www.haskell.org/libraryInfrastructure/proposal/index.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
