Le jeudi, 8 mars 2012 à 22:27, Sylvain Le Gall a écrit :

> It does it the right way ;-)
  

The "I'm going to vomit files across your whole file system so that you need 
another bureaucratic tool/database too keep track of what I did whenever you 
want to remove me" way. Sure if you're looking for a business model and more 
bureaucracy that's the way to do it the "right way". The key insight in things 
like gnu stow or homebrew is that this tool/database already exists, it's the 
file system itself, KISS principle. And this simplicity also allows you to deal 
very easily with multiple version installs of the same package.

> I would probably object to have html documentation in the $SITELIB of
> findlib.  


To me that seems to be an ideological objection (debian related I guess), I 
don't see any technical objection. KISS should be applied here: I installed 
that package in that directory anything related to it is in that single 
directory.

> I think a CHANGES/README is light enough to be in $SITELIB as well.

CHANGES and README light, html heavy ? For one thing keep it at least 
consistent either you choose to put nothing in SITELIB or everything. I don't 
want to have to lookup two different places for documentation.

> To be honest, if it was the only problem I have to solve, I'll be happy to 
> spend hours on that.

I don't think it's a good idea for the whole system to underestimate the 
importance of documentation.  

> But all this need to be more widely discuss (with OCamlPro for
> TypeRex, Maxence for .odoc/Cameleon, Gerd for ocamlfind and the rest
> of the community to have a real agreement on this point).


I'm all for it, but now that I'm in these things I want to move forward. So 
what should I write something like this (currently) nop ?  

Document xmlm
Title: "Xmlm documentation and module reference"
Format: html
Index: Xmlm.html  
Install: true
InstallDir: $docdir
DataFiles: CHANGES README doc/*.html, doc/*.css

Or should I make another Document for CHANGES README ?  

> Well _oasis can also go there, even though it will be a little bit a
> duplicate with META...


It also has much more information in a machine readable format. Like the home 
page of the project, the maintainers, maybe even the repos etc.  

Best,

Daniel


-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Reply via email to