[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy ready to be edited



On Sun, Oct 19, 2003 at 10:33:26AM +0200, Stefano Zacchiroli wrote:
> On Sun, Oct 19, 2003 at 10:27:36AM +0200, Jérôme Marant wrote:
> > > As we have discussed on friday night :
> > > - choose between putting META file either in stdlibdir/META.package
> > >   or stdlibdir/package/META ( we have choose the second one because it is
> > >   the default way of doint this with ocamlfind... )
> > Both solution should be allowed because both are allowed by
> > findlib.
> 
> I haven't had a look at the policy document committed by Sylvain, but
> mainly the idea should be _not_ to mandate where to install META files.
> This remark is just because a few time ago we wondered about decide a
> common location to place META files. IMO the only requirement we should
> have is this META files are installed in a place which permits to
> findlib to find the packages. stdlib/libdir/META is ok, stdlib/META.pkg
> is ok, stdlib/libdir/META.pkg is not ok.

Well, i would much prefer to have the META.pkg in a defined subdir of
stdlib, and not clutter the stdlib directory any further.

Also remember the decision we took some time back. stdlib is for
official ocaml stuff only. all third party libraries need to go in a
subdir named after the library, and put their dll.so in stublibs.

The same should be done for meta, put them either in foo/META, or in
METADIR/META.pkg. I wish to not see them in stdlib if possible.

> > > - define a way to ship documentation generated by package or mli
> > >   translation through ocamldoc :
> > >    - my idea : create an ocamldoc-base package containing a script able
> > >      to convert "ocamldoc.... -dump package.odoc" through "ocamldoc -load
> > >      package.odoc .... (-html|-man|... )" to html, manpages...
> > >    - zack idea : just use ocamldoc to generate html documentation in the
> > >      package.
> > You seem to give solutions, but what is the problem?
> 
> It depends on your idea of "problem". If problem is just "something not
> working" we have no problem, if problem is "something that can be
> improved", the problem is that we have no documentation of the API
> installed by the various library and we can easily automatically
> generate them where they aren't available.

And add them to the debian documentation stuff.

> The idea here is to have a debhelper or something similar which can be
> invoked in debian/rules and automatically generate documentation for the
> .mli files he found, register the result with doc-base and so on.

Mmm, so in your idea, it would be the packages responsability to build
and register the docs with the help of a dh_ocamldoc helper script, but
with Sylvain's idea, ... not sure about sylvain's idea, i think it is
the same here, and the difference is in the manner of genrating the
documentation.

Friendly,

Sven Luther
> 
> Cheers.
> 
> -- 
> Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
> zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
> "  I know you believe you understood what you think I said, but I am not
> sure you realize that what you heard is not what I meant!  " -- G.Romney




Reply to: