Le 15 janv. 08 à 14:38, Berke Durak a écrit :

> I think we should rather add to Ocamlbuild a module for calling  
> ocamlfind, parsing its output, etc. This way ocamlbuild plugins  
> could easily call ocamlfind, be it for configuration or compilation.

My problem with ocamlfind is that it takes too much control over me.  
Also it doesn't help you with the tedious publishing aspect (which I  
try to mitigate by using news feeds) and it won't help you with the  
binary update problem.

Le 15 janv. 08 à 16:07, Sylvain Le Gall a écrit :

> Unfortunately, a decentralized system has also several drawbacks:
[...]

Yes of course. But the point is that we already have a decentralized  
system. All these tarballs that are referenced from the hump and not  
part of godi. My aim is to be able to quickly install or publish such  
decentralized bits. Currently these two tasks take too much time:  
using them, because everyone does it its own way, publishing them,  
because you have to devise your own way (make a readme, think about  
how to structure the tarball how to manage releases, announce on the  
mailing list, etc.). The idea is to simplify all this uninteresting  
business to entice people to share their modules. Lowering the bar may  
mean a decrease in quality but in the end good modules and reliable  
publishers will be identified by the community.

Also note that the proposal in itself doesn't prevent the development  
of a more authoritative, centralized and stable source of packages.

> In fact, Debian user reading this will see that i am having the same
> sort of arguments that Debian has concerning the other distributions.
> Debian has developped a very centric repository for all its packages
> which other Linux distribution have not done. This tends to lead to  
> have
> more control on the QA of everything. Which is better to my mind.

If the aim is to support an operating system I completly agree with  
you. But the aim of my proposal is to support the ocaml development  
bazaar which is not the same thing.

>> 3. Manage packages per project (vs. per machine) to make project
>> dependencies explicit. Thus a single command can install you the
>> (OCaml + C stubs only) dependencies of your project on a fresh  
>> system.
>> If your project is a package itself, it facilitates its packaging .
>>
>
> I don't agree project and package are not the same thing. You should
> take into consideration that different distribution have different
> packaging policy.

That's not what I say. The _if_ of the last sentence is for when you  
are developing an ocaml library with dependencies in that case your  
project may become a package. If you are making an end-user  
application this should not be used as a distribution mechanism, I  
explicitly say that in the proposal, it is a tool for ocaml  
_developers_. But still from a developer perspective it is a good  
thing to have a mechanical way to track the external dependencies of  
your project whether this is an end-user application or not, hence  
packages should be (conceptually) managed per project.

Best,

Daniel