Seems like maybe the beginnings of a minimalist proposal are beginning to
emerge from the discussion...

   - Using a "hump" model -- centrally stored meta-data pointing to
     actual package contents stored on people's individual servers and
     updated at will -- avoids uploading/mirroring issues.

     In fact, the current hump seems almost right -- it just needs
        - to be minimally machine readable (perhaps just able to export
          its DB in some simple XML format)
        - to have some way of indicating dependencies
        - to include pointers directly to package contents (not to
          people's web pages where packages can be found, etc.)

     For a notation for signalling dependencies, a little work is needed.
     But I have the impression that there are a number of people in the
     community that understand the issues rather well, and that a pretty
     simple solution would be good enough for 99.9% of the cases...

     For pointers to package contents, one should establish a common file
     naming convention -- e.g., record the URL of the package contents in
     the COAN as

         http://hostname.fr/path/mynicepackage-VERSION.tar.gz

     and store versions 1.2, 1.3, 1.5 on the server as

         http://hostname.fr/path/mynicepackage-1.2.tar.gz
         http://hostname.fr/path/mynicepackage-1.3.tar.gz
         http://hostname.fr/path/mynicepackage-1.5.tar.gz

   - Let people write their makefiles in whatever way they like, use
     findlib or not as they prefer, etc., but establish a minimal set
     of common requirements -- e.g. 
         - saying just 'make install' should do configuration if
           necessary, build bytecode and (if possible) native versions,
           and put them where they belong 
         - DESTDIR should be treated appropriately
         - etc.

     Again, there are several people in the community that have, among
     them, a pretty clear sense of what these minimal requirements should
     look like.  (I know there is some disagreement about details, but as
     a developer I don't really care -- I just want someone to decide on
     something reasonable and publish a template that I can follow if I
     want to contribute my code to the community.)  I'd love it if three
     or four of them could just get together, decide something
     reasonable, discuss it with the OCaml authors to make sure they
     agree, and tell the rest of us what to do.

I nominate Marcus, Jean-Christophe, Gerd, and Sven.  :-)

    -- Benjamin


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners