[Caml-list] Project Proposals

[Caml-list] Project Proposals

[Diego Olivier Fernandez Pons]

    Bonjour,

J'ai constaté la présence de la rubrique "Project proposals" dans les
bosses Caml - d'ailleurs il en avait été question auparavant dans
quelques messages de cette liste -

Mes questions à ce sujet sont les suivantes :

- quel est le type de proposition visée (petit projet similaire à
celui qu'on donnerait à un étudiant en stage ? projets moyens ? grands
développements ? portages ? tous les précedents ?)

- qui sont les personnes "autorisées" à faire ces propositions si
j'ose dire et existe-t-il un "controle" quelconque ?

- quels sont les prérequis (description de la proposition je suppose,
mais dans quel format ? faut-il y inclure des liens ? une
bibliographie ?) La réponse à cette question est sans doute liée à la
première (nature des propositions) car un portage peut se contenter
d'un lien vers un projet similaire dans un autre langage par exemple,
là où un sujet de type "stage" requiert une bibliographie plus
importante.

- pourrait-on y inclure des projets en cours de développement ? (Je
pense par exemple au projet Bedouin ...)

        Diego Olivier
-------------------
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

Re: [Caml-list] Project Proposals

[Xavier Leroy]

Some answers for Diego's questions about the new "Project proposals"
section of the Caml Hump:

- Nature of the proposed work: I think everything goes, from short
projects (a few modules) to more ambitious, long-term developments
(interfaces with large libraries, design and implementation of
complete frameworks, etc).  Still, it's better if the project is
relatively self-contained and can be described relatively precisely.
E.g. "implementing the TLS protocol" is fine, but "design and
implement a new protocol for authentication and confidentiality over
the Web" is perhaps too imprecise (and too ambitious :-).

- Who can make proposals and how they are selected: everyone is
welcome to make proposals, either on this list or by mailing
hump@pauillac.inria.fr.  Maxence Guesdon maintains the Humps,
and asks us (the Caml team) if there are questions on the
appropriateness of a topic.

- How to make a proposal: a one-liner plus a link to relevant
documentation or specification is fine, e.g. "a library to handle MIME
encoding and mailbox parsing" with a link to the relevant RFC.  If you
wish to provide more details, you're most welcome to write a more
complete description on a Web page, and send us the URL.

- Should we include links to projects already in progress
(e.g. Bedouin): why not, if the organizers of these projects wish to
(maybe they have enough volunteers already).

Hope this answers your questions,

- Xavier Leroy
-------------------
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

[Caml-list] OCaml packaging problems

[Vitaly Lugovsky]

 Hi!

 I'm having a big troubles packaging OCaml and 3rd party
libraries (like lablGL, lablgtk) in RPM. All the evil is in 
the ld.conf file - foreign libraries should add lines in 
it at the installation.

 The much better approach to the multi-package configurations
is introduced, e.g. in xinetd, new crontabs, and so on - all
external packages writes their configuration files or even
just a symlinks to the special directory. So, it'll be better to
have a special directory like ld.conf.dir/ with symlinks to
the actual dynamic library paths, which will be updated safely
when new packages are installed/removed. But, we've no directory
access functions in the Pervasives library, and Unix library is
not accessible from the runtime - we can't rewrite dll.ml to
use this approach. May be, it'll be nice to provide some basic
directory access functionality from Pervasives?


-------------------
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

Re: [Caml-list] OCaml packaging problems

[Remi VANICAT]

Vitaly Lugovsky <vsl@ontil.ihep.su> writes:

>  Hi!
> 
>  I'm having a big troubles packaging OCaml and 3rd party
> libraries (like lablGL, lablgtk) in RPM. All the evil is in 
> the ld.conf file - foreign libraries should add lines in 
> it at the installation.

The debian ocaml package use the following method :

- the ocaml package contain an executable (ocaml-ldconf) which is in
  charge of the generation of the ld.conf
- it use a file (/var/lib/ocaml/ld.conf) that contain line which look
  like /usr/lib/ocaml/lablgtk  add     liblablgtk-ocaml
  that mean : the liblablgtk-ocaml package have add the
  /usr/lib/ocaml/lablgtk directory to the /usr/lib/ocaml/ld.conf file 
  (it also use the /etc/ocaml/ld.conf file for addition of new
  directory by the administrator)

so when a new package is installed, it run in its postinst script
things like
ocaml-ldconf -pliblablgtk-ocaml -a /usr/lib/ocaml/lablgtk

and when it is remove it run in its prerm script :
ocaml-ldconf -pliblablgtk-ocaml -r /usr/lib/ocaml/lablgtk

and the ocaml-ldconf take care of every thing else...



> 
>  The much better approach to the multi-package configurations
> is introduced, e.g. in xinetd, new crontabs, and so on - all
> external packages writes their configuration files or even
> just a symlinks to the special directory. So, it'll be better to
> have a special directory like ld.conf.dir/ with symlinks to
> the actual dynamic library paths, which will be updated safely
> when new packages are installed/removed. But, we've no directory
> access functions in the Pervasives library, and Unix library is
> not accessible from the runtime - we can't rewrite dll.ml to
> use this approach. May be, it'll be nice to provide some basic
> directory access functionality from Pervasives?

You may also add a dll/ directory with link to each dll...
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven]

On Tue, Apr 30, 2002 at 05:28:38PM +0400, Vitaly Lugovsky wrote:
> 
>  Hi!
> 
>  I'm having a big troubles packaging OCaml and 3rd party
> libraries (like lablGL, lablgtk) in RPM. All the evil is in 
> the ld.conf file - foreign libraries should add lines in 
> it at the installation.

Have a look at the debian package and the solution we have adopted there.

Basically there are now 3 different files :

/usr/lib/ocaml/ld.conf (the normal one) which is autogenerated by ocaml-ldconf
from the two other ones.

/etc/ocaml/ld.conf which can be filled by the administrator to override the
dpkg generated one. (it has per line, a directory, and the command word
add/addafter/remove).

/var/lib/ocaml/ld.conf which is filled by a special prerm/postinst script, and
contains, not only the directory to add to ld.conf, but also the package
where this path originate. a package can provide more than one such path.

It works rather nicely, altough the ocaml-ldconf program could use some
enhancement (i wrote it hastily, but it does the job and was further
fool-tested during the debian testing process).

If this seems agreable to you, feel free to reuse any part of this scheme (the
ocaml-ldconf.ml file is GPLed though, there is a basic manpage i think, and i
don't think the debhelper scripts would be usefull in a rpm context).

I also needed to add a small patch to ocam lso it will not accept comment in
the ld.conf file, but apart form that, no changes were needed.

If more people like this scheme, it could even be considered for upstream
adoption.

>  The much better approach to the multi-package configurations
> is introduced, e.g. in xinetd, new crontabs, and so on - all
> external packages writes their configuration files or even
> just a symlinks to the special directory. So, it'll be better to
> have a special directory like ld.conf.dir/ with symlinks to
> the actual dynamic library paths, which will be updated safely
> when new packages are installed/removed. But, we've no directory

That would be another solution, 

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Xavier Leroy]

Concerning this ld.conf issue, I disagree both with Sven Luther's solution
(a tool that adds/removes lines from this file) and with Vitaly
Lugovsky's suggestion (multiple configuration files in a directory).

The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
by the Unix dynamic loader.  It is intended to list a small number of
standard directories that contain shared libraries, typically one
directory for the "system" libraries (i.e. those provided by the OCaml
core distribution), one for local extensions (e.g. /usr/local/lib),
and perhaps one or two for especially large packages with many libraries
(e.g. /usr/X11R6/lib).  

When you install a package that provides a C shared library, you don't
install it in a package-dependent directory and add a line to
/etc/ld.so.conf with this directory; you install in /usr/lib or
/usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
the same scheme for OCaml shared libraries.

(And, yes, I haven't followed this recommendation in some of the
standard OCaml libraries (labltk) or some of my own extensions,
but I've realized my error and intend to fix this in release 3.05.)

So, to summarize, I strongly suggest the following approach for RPMs
or Debian packages:
- The main Caml package can add one or two lines to ld.conf,
  e.g. /var/lib/ocaml/shlibs (for libraries installed by other packages)
  and /usr/local/lib/ocaml/shlibs (for local stuff)
- Packages for additional Caml libraries install their shared libraries
  in /var/lib/ocaml/shlibs, either directly or via a symlink.

This is simple, consistent with C shared libraries, and supports
deinstallation of additional Caml libraries without any hassle.

- Xavier Leroy
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Stefano Zacchiroli]

On Tue, May 14, 2002 at 10:54:52AM +0200, Xavier Leroy wrote:
> When you install a package that provides a C shared library, you don't
> install it in a package-dependent directory and add a line to
> /etc/ld.so.conf with this directory; you install in /usr/lib or
> /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> the same scheme for OCaml shared libraries.

Before proposing such a solution is better to reach an agreement among
the community of OCaml libraries developer.

I've built a lot of debian packages containing ocaml library shared and
not. Almost of them assume that all the library files will be installed
to a _single_ directory, including in "library files": ml and mli files,
cm? files and shared objects. Installing all this stuff in a single
directory will cause rapidly name clashes.

The right(TM) solution seems to be: install shared object files in a
single directory listed in OCaml's ld.conf _but_ install all other stuff
in a per-package directory that needs not to be listed in ld.conf.

Right now I know no package that supports two different destination
directory as install flags. This is a tiny problem, but requires changes
in a lot of packages.

Please, don't require that all the library stuff will reside in a single
directory.

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"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
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Jacques Garrigue]

From: Xavier Leroy <xavier.leroy@inria.fr>
Date: Tue, 14 May 2002 10:54:52 +0200

> Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> (a tool that adds/removes lines from this file) and with Vitaly
> Lugovsky's suggestion (multiple configuration files in a directory).

I was always wondering about the need for removing any directory from
ld.conf: it the directory is not there, there will be no problem
anyway...

> The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> by the Unix dynamic loader.  It is intended to list a small number of
> standard directories that contain shared libraries, typically one
> directory for the "system" libraries (i.e. those provided by the OCaml
> core distribution), one for local extensions (e.g. /usr/local/lib),
> and perhaps one or two for especially large packages with many libraries
> (e.g. /usr/X11R6/lib).  
> 
> When you install a package that provides a C shared library, you don't
> install it in a package-dependent directory and add a line to
> /etc/ld.so.conf with this directory; you install in /usr/lib or
> /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> the same scheme for OCaml shared libraries.

It's not because Unix does something wrong that you have to follow it.
In the past I was installing libraries somewhere else (using --prefix
in most packages) and using -rpath. The trouble is that -rpath is
broken on some Unices, so I've reverted to making symbolic links to
/usr/local/lib for the soname. Otherwise it's a pain to manage.

Now I don't think that the current scheme in caml is perfect, but to
me it works ok. When I delete a library I just delete its directory,
and I'm sure it's clean.

> (And, yes, I haven't followed this recommendation in some of the
> standard OCaml libraries (labltk) or some of my own extensions,
> but I've realized my error and intend to fix this in release 3.05.)

I'm the culprit. And well, I have no definite opinion about libraries in
the standard distribution, just that they set an example.
Note that moving dlls around _is_ dangerous, because you may
end-up with dlls with the same name in different place when
overwriting an existing installation.

By the way, if you're so fond of the C way, using versioning on dlls
would be very useful about this kind of problems (with the version in
the .cma, rather than using symbolic links!)

Cheers,

        Jacques
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Michal Moskal]

On Tue, May 14, 2002 at 10:54:52AM +0200, Xavier Leroy wrote:
> So, to summarize, I strongly suggest the following approach for RPMs
> or Debian packages:
> - The main Caml package can add one or two lines to ld.conf,
>   e.g. /var/lib/ocaml/shlibs (for libraries installed by other packages)
>   and /usr/local/lib/ocaml/shlibs (for local stuff)
> - Packages for additional Caml libraries install their shared libraries
>   in /var/lib/ocaml/shlibs, either directly or via a symlink.

Hmm.. when perparing rpms with OCaml packages for PLD Linux I first
created /usr/lib/ocaml/dlls and put dll*.so from all packages (including
main OCaml package) there directly. However it caused problems with
ocamlmktop (IIRC, ocamlc worked fine), so I ended up with dllfoo*.so 
in /usr/lib/ocaml/foo and symlinks in /usr/lib/ocaml (and just 
/usr/lib/ocaml in ld.conf).

AFAIK /var/lib/ocaml isn't good place for installation on any binary
stuff. /usr/lib/ocaml should be used, as it can be read only. /var is
for data that programs change. There is nothing to change in dynamic
library after it is installed. Please reffer to FHS for details.

-- 
: Michal Moskal :::::::: malekith/at/pld.org.pl :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Michal Moskal]

On Tue, May 14, 2002 at 08:39:54PM +0900, Jacques Garrigue wrote:
> > The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> > by the Unix dynamic loader.  It is intended to list a small number of
> > standard directories that contain shared libraries, typically one
> > directory for the "system" libraries (i.e. those provided by the OCaml
> > core distribution), one for local extensions (e.g. /usr/local/lib),
> > and perhaps one or two for especially large packages with many libraries
> > (e.g. /usr/X11R6/lib).  
> > 
> > When you install a package that provides a C shared library, you don't
> > install it in a package-dependent directory and add a line to
> > /etc/ld.so.conf with this directory; you install in /usr/lib or
> > /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> > the same scheme for OCaml shared libraries.
> 
> It's not because Unix does something wrong that you have to follow it.
> In the past I was installing libraries somewhere else (using --prefix
> in most packages) and using -rpath. The trouble is that -rpath is
> broken on some Unices, so I've reverted to making symbolic links to
> /usr/local/lib for the soname. Otherwise it's a pain to manage.
> 
> Now I don't think that the current scheme in caml is perfect, but to
> me it works ok. When I delete a library I just delete its directory,
> and I'm sure it's clean.

Unix gets it right. That's what package managers are for. You do
rpm -e foobar (or equivalent) and that's all.

Looking in multiple directories takes time. Think how much would it
take to check hundred of directories, which is no more then avarage
linux installation have C libraries. Similar can be told about /usr/bin
and <tab> in shell.

-- 
: Michal Moskal :::::::: malekith/at/pld.org.pl :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Xavier Leroy]

> The right(TM) solution seems to be: install shared object files in a
> single directory listed in OCaml's ld.conf _but_ install all other stuff
> in a per-package directory that needs not to be listed in ld.conf.

That's exactly what I had in mind -- perhaps even with a symlink for
the shared objects.  

> Please, don't require that all the library stuff will reside in a single
> directory.

That wasn't what I had in mind, but probably I wasn't clear enough.

- Xavier Leroy
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Gerd Stolpmann]

On 2002.05.14 10:54 Xavier Leroy wrote:
> Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> (a tool that adds/removes lines from this file) and with Vitaly
> Lugovsky's suggestion (multiple configuration files in a directory).
> 
> The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> by the Unix dynamic loader.  It is intended to list a small number of
> standard directories that contain shared libraries, typically one
> directory for the "system" libraries (i.e. those provided by the OCaml
> core distribution), one for local extensions (e.g. /usr/local/lib),
> and perhaps one or two for especially large packages with many libraries
> (e.g. /usr/X11R6/lib).  

Traditionally, Unixes try to minimize the directories that contain
code, i.e. executables and (later) shared libraries are stored in only
a few directories. Today people tend to justify this way of managing 
code without realizing that it is the consequence of a design 
decision of the operating system, and not naturally the best choice.

The point is that important parts of the program loader run in userland,
and not inside the kernel. Especially searching the libraries is done for
every started program again, because it is not possible to have an index 
that could speed this process up. At least an automatic index is not
possible (you would need hooks on file system operations for it, and that
would require modifications in the kernel, e.g. a filesystem with
database capabilities). Some Unixes have such an index,  but it must be 
manually updated (ldconfig).

This means: The lack of a certain facility is the reason why Unix organizes
the directories by its operational needs, and not "by package", or in a
completely different way.
 
> When you install a package that provides a C shared library, you don't
> install it in a package-dependent directory and add a line to
> /etc/ld.so.conf with this directory; you install in /usr/lib or
> /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> the same scheme for OCaml shared libraries.

In my opinion, there is no real reason why ocaml should follow the Unix
example, because the ocaml loader needs not to manage the whole system,
and has much lower scalability requirements. Currently I have 9 directories
in my ld.conf, and even if I had twenty directories I would not notice
any significant startup deferrals. (Yes, the search needs quadratic
time, but the file system cache helps very much to keep the costs
low.)

Furthermore, for users with much higher requirements it is possible to
implement the index like some of the Unix loaders do: by an ld.cache
that must be updated by starting an update program.

Finally, I want to point out that ocaml views the C libraries primarily as 
_dynamic_ libraries and not _shared_ libraries, so a shared directory
is conceptually misleading. The cma is shared, not the C library behind
it. Ideally, there would be a unique ID that joins the cma and the C
library, and that makes the association between the cma and the C library
exclusive. (So no other cma can load the C library, e.g. because I have
installed several versions of the same module with the danger of a
name clash.)

Well, again we would need database capabilities to do the job right...
Nobody can generate such a unique ID for us.

> (And, yes, I haven't followed this recommendation in some of the
> standard OCaml libraries (labltk) or some of my own extensions,
> but I've realized my error and intend to fix this in release 3.05.)

Which error? Too less directories!
 
> So, to summarize, I strongly suggest the following approach for RPMs
> or Debian packages:
> - The main Caml package can add one or two lines to ld.conf,
>   e.g. /var/lib/ocaml/shlibs (for libraries installed by other packages)
>   and /usr/local/lib/ocaml/shlibs (for local stuff)
> - Packages for additional Caml libraries install their shared libraries
>   in /var/lib/ocaml/shlibs, either directly or via a symlink.
> 
> This is simple, consistent with C shared libraries, and supports
> deinstallation of additional Caml libraries without any hassle.

Yes, for packaged ocaml installations this is the simplest solution. But
not everybody uses such installations, and for manually maintained systems
this way introduces another source for errors. 

My summary is different: The Unix way of handling shared library is driven
by operational requirements (fast library lookup), and is conceptually not
the best choice. In a better world, it would be possible to link programs
with libraries in a very controlled way, but that would require database
capabilities on the filesystem layer. However, for the needs of a small
subsystem like ocaml, it is not hopeless to maintain the required index
tables manually.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Jacques Garrigue]

From: Michal Moskal <malekith@pld-linux.org>
> On Tue, May 14, 2002 at 08:39:54PM +0900, Jacques Garrigue wrote:
> > > The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> > > by the Unix dynamic loader.  It is intended to list a small number of
> > > standard directories that contain shared libraries, typically one
> > > directory for the "system" libraries (i.e. those provided by the OCaml
> > > core distribution), one for local extensions (e.g. /usr/local/lib),
> > > and perhaps one or two for especially large packages with many libraries
> > > (e.g. /usr/X11R6/lib).  
> > > 
> > > When you install a package that provides a C shared library, you don't
> > > install it in a package-dependent directory and add a line to
> > > /etc/ld.so.conf with this directory; you install in /usr/lib or
> > > /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> > > the same scheme for OCaml shared libraries.
> > 
> > It's not because Unix does something wrong that you have to follow it.
> > In the past I was installing libraries somewhere else (using --prefix
> > in most packages) and using -rpath. The trouble is that -rpath is
> > broken on some Unices, so I've reverted to making symbolic links to
> > /usr/local/lib for the soname. Otherwise it's a pain to manage.
> > 
> > Now I don't think that the current scheme in caml is perfect, but to
> > me it works ok. When I delete a library I just delete its directory,
> > and I'm sure it's clean.
> 
> Unix gets it right. That's what package managers are for. You do
> rpm -e foobar (or equivalent) and that's all.

Sure, since this is the Unix way :-)
Package manager are strange beasts, in my opinion overstressed by the
fact they have to install files all over the place.
If Unix had really got it right, there would be no need for file
tracking in package managers, only dependency tracking.
Also, there are plenty of them, and not every ocaml library come with
what is needed to work with a some specific package manager. Most
actually work with none.

> Looking in multiple directories takes time. Think how much would it
> take to check hundred of directories, which is no more then avarage
> linux installation have C libraries. Similar can be told about /usr/bin
> and <tab> in shell.

Not really: ldconfig is caching the contents of directories in
ld.so.conf anyway, so that having lots of directory incurs only a mild
cost at system startup (and reconfiguration).

Anyway, when I said that Unix was wrong, I was not talking of
performance but of functionality. I'm not sure that having a very
long list of directories in ld.so.conf is a good solution,
just that having to put all shared libraries in the same directory is
a pain, and that something should be done about it.  After various
attempts, Unix seems to have dropped the issue (tampering directly
with ld.so.conf on a running system being a bit dangerous for the
faint of heart, LD_LIBRARY_PATH is kind of a hack)

I have no miracle solution, but the current one seemed to be ok.
If we revert to a solution based on a specific directory for dlls
(preferably not lib/ocaml but lib/ocaml/shlibs), then I would add
symbolic links to there, rather than put libraries directly there and
get compatibility problems later. But symbolic links have their own
problems, and do not work well with Windows.

Cheers,

Jacques
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Jacques Garrigue]

While I was trying to answer on the limitations of the Unix approach,
Gerd Stolpmann posted a much better and well-argument description of
the problem.

To complement this, I would add a suggestion to make the current
scheme work more smoothly.  It takes its inspiration from java's
classpath, which seems to work pretty well:
Couldn't we replace the single directory in OCAMLLIB by a path.
Alternatively, there could be an OCAMLPATH, taking precedence on
OCAMLLIB.
This path would replace the current stdlib for everything:
* it would be a default path for searching caml libraries and dlls
* ld.conf's under each of its elements would be read in its order
* +dirname on the command line would expand to elt/dirname for each
  of its elements
* findlib might honour it too

This would in particular solve the current problem with users who do
not have write access on the main library tree, and allow more
flexibility. This is of course orthogonal to the dependency handling
done by findlib.

For library designers, they would just have to honour this
variable by installing by default under the first element of this
path, adding the directory to elt/ld.conf if they also install dlls.

In my opinion simple (one variable), standard (think Java), and clean.

Jacques
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven Luther]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 6194 bytes --]

On Tue, May 14, 2002 at 10:54:52AM +0200, Xavier Leroy wrote:
> Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> (a tool that adds/removes lines from this file) and with Vitaly
> Lugovsky's suggestion (multiple configuration files in a directory).

Would you care to argument a bit more about this, apart from the 'it is
not the unix way' argument you give below that is.

and BTW, ocaml-ldconf does not really add/remove lines from the
/usr/lib/ocaml/ld.conf file, it uses two separate files
(/etc/ocaml/ld.conf and /var/lib/ocaml/ld.conf) which are modified and
used to generate the /usr/lib/ocaml/ld.conf.

It is a nice concept (even if it is me saying it) that clearly separate
the system administrator stuff (/etc/ocaml/ld.conf) from the
dpkg/rpm/whatever handled stuff (/var/lib/ocaml/ld.conf), with the
former taking precedence over the later. In no way does it modify the
way ocaml handles this, and is thus a purely external tool doing its
jjob correctly.

> The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> by the Unix dynamic loader.  It is intended to list a small number of
> standard directories that contain shared libraries, typically one
> directory for the "system" libraries (i.e. those provided by the OCaml
> core distribution), one for local extensions (e.g. /usr/local/lib),
> and perhaps one or two for especially large packages with many libraries
> (e.g. /usr/X11R6/lib).  

So, what is the way we want to handle this ? Do we put all stuff related
to libraries in a sub directory, like we were doing up to now, or do we
revert to the name space poluting 'all in the same dir' concept ? If you
do it the later way, this is a 180 degree turn from your previous
position, and the one followed by most current libraries.

Also, notice that in the above, you don't take into account the
libraries provided by the OS distributor, which upto now did put their
library stuff under a subdir of OCAMLLIBDIR.

> When you install a package that provides a C shared library, you don't
> install it in a package-dependent directory and add a line to
> /etc/ld.so.conf with this directory; you install in /usr/lib or
> /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> the same scheme for OCaml shared libraries.

Well, if i remember well, the true C shared library is not really stored
in /etc/ld.conf, but rather in some other space, and it is only the
ldconfig tool which (from the manbpage)

       ldconfig creates the necessary links and cache (for use by
       the  run-time  linker,  ld.so)  to  the most recent shared
       libraries found in the directories specified on  the  com­
       mand line, in the file /etc/ld.so.conf, and in the trusted
       directories (/usr/lib  and  /lib).   ldconfig  checks  the
       header  and file names of the libraries it encounters when
       determining  which  versions  should  have   their   links
       updated.   ldconfig  ignores  symbolic links when scanning
       for libraries.

So if you trully want to do comparaisons, such a tool would be nice (and
one that handles different versions even better :)))

And about the symlink issue ? Why resort to it, if you can do it in a
more clean way ? And if you are afraid of lot of incompatible changes,
remember the ocaml-ldconf tool from the debian distribution handles our
problem well and without interference on how ocaml does handle it.

> (And, yes, I haven't followed this recommendation in some of the
> standard OCaml libraries (labltk) or some of my own extensions,
> but I've realized my error and intend to fix this in release 3.05.)

There is nbo clear policy on that, and everyone does it their own way,
or maybe the way they feel is the correct one, gathering it from how the
inria people do with the libraries they release. It is mostly a
guesswork thing, and would very much benefit from a 'standardisation' of
such practives.

Also, before you 'fix' things things in 3.05, maybe more based of a spur
of the moment decision you are taking (which may not be the case, but
seems so from your revirement from previous practices), i would very
much like to have a true and open discution on this important subject,
before any such decision is taken, but then, in the end it is you who
decide on this (and i can always do the patching for the debian package
:)))

> So, to summarize, I strongly suggest the following approach for RPMs
> or Debian packages:
> - The main Caml package can add one or two lines to ld.conf,
>   e.g. /var/lib/ocaml/shlibs (for libraries installed by other packages)
>   and /usr/local/lib/ocaml/shlibs (for local stuff)

Ok, but why not put them in subdir like it is done all over the place
right now ? (and what precedence will you use for the local over
standard packages ? Or coiuld you choose a finer granularity for such
choice ?)

> - Packages for additional Caml libraries install their shared libraries
>   in /var/lib/ocaml/shlibs, either directly or via a symlink.

Ok, i could live with that, _if_ you convince me that it is a better
solution than the one available right now. 

Also a quick note about name space pollution, mayube it is not an issue,
since you cannot anyway have two shared stub library of the same name,
even in two different directories, isn't it ? So there is nothing gained
by putting things in different dirs.

> This is simple, consistent with C shared libraries, and supports
> deinstallation of additional Caml libraries without any hassle.

Just two things to conclude, first notice that on most system, C
libraries are also put in subdirectories of /usr/lib, and this works ok,
which is not currently the case in ocaml, and second I would _much_ have
preferred you take such a stance 6 month ago, before we took the pain to
discuss a viable solution for the debian ocaml related packages, and i
lost times working on this back then.

Friendly,

Sven Luther
> 
> - Xavier Leroy
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven Luther]

On Tue, May 14, 2002 at 08:39:54PM +0900, Jacques Garrigue wrote:
> From: Xavier Leroy <xavier.leroy@inria.fr>
> Date: Tue, 14 May 2002 10:54:52 +0200
> 
> > Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> > (a tool that adds/removes lines from this file) and with Vitaly
> > Lugovsky's suggestion (multiple configuration files in a directory).
> 
> I was always wondering about the need for removing any directory from
> ld.conf: it the directory is not there, there will be no problem
> anyway...

So, you prefer to clutter the /usr/lib/ocaml/ld.conf file rather than
have a convenient tool for removing a line there when you remove the
package they belong to ? Remember, clutter is an open way to insecure
behavior ...

> > The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> > by the Unix dynamic loader.  It is intended to list a small number of
> > standard directories that contain shared libraries, typically one
> > directory for the "system" libraries (i.e. those provided by the OCaml
> > core distribution), one for local extensions (e.g. /usr/local/lib),
> > and perhaps one or two for especially large packages with many libraries
> > (e.g. /usr/X11R6/lib).  
> > 
> > When you install a package that provides a C shared library, you don't
> > install it in a package-dependent directory and add a line to
> > /etc/ld.so.conf with this directory; you install in /usr/lib or
> > /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> > the same scheme for OCaml shared libraries.
> 
> It's not because Unix does something wrong that you have to follow it.
> In the past I was installing libraries somewhere else (using --prefix
> in most packages) and using -rpath. The trouble is that -rpath is
> broken on some Unices, so I've reverted to making symbolic links to
> /usr/local/lib for the soname. Otherwise it's a pain to manage.

Mmm, there is a long discution on some of the debian lists (well a
flamewar would be a more correct name) with one side claiming that rpath
are evil, and can lead to problems if the files are moved around later
one (example cited was the moving of the /usr/X11R6 directory, probably
because you want to install a new X server while keeping the old one).

> Now I don't think that the current scheme in caml is perfect, but to
> me it works ok. When I delete a library I just delete its directory,
> and I'm sure it's clean.
> 
> > (And, yes, I haven't followed this recommendation in some of the
> > standard OCaml libraries (labltk) or some of my own extensions,
> > but I've realized my error and intend to fix this in release 3.05.)
> 
> I'm the culprit. And well, I have no definite opinion about libraries in
> the standard distribution, just that they set an example.
> Note that moving dlls around _is_ dangerous, because you may
> end-up with dlls with the same name in different place when
> overwriting an existing installation.

unless you have a package manager handling things :)))

> By the way, if you're so fond of the C way, using versioning on dlls
> would be very useful about this kind of problems (with the version in
> the .cma, rather than using symbolic links!)

:)))

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Vitaly Lugovsky]

On Wed, 15 May 2002, Sven Luther wrote:

> > Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> > (a tool that adds/removes lines from this file) and with Vitaly
> > Lugovsky's suggestion (multiple configuration files in a directory).
> 
> Would you care to argument a bit more about this, apart from the 'it is
> not the unix way' argument you give below that is.
> 
> and BTW, ocaml-ldconf does not really add/remove lines from the
> /usr/lib/ocaml/ld.conf file, it uses two separate files
> (/etc/ocaml/ld.conf and /var/lib/ocaml/ld.conf) which are modified and
> used to generate the /usr/lib/ocaml/ld.conf.
> 
> It is a nice concept (even if it is me saying it) that clearly separate
> the system administrator stuff (/etc/ocaml/ld.conf) from the
> dpkg/rpm/whatever handled stuff (/var/lib/ocaml/ld.conf), with the
> former taking precedence over the later. In no way does it modify the
> way ocaml handles this, and is thus a purely external tool doing its
> jjob correctly.

 This concept looks like ls-R file in the teTeX distribution. And all
packagers knows that this file is quite a problem. So, as for me,
I choosed the way suggested by Xavier Leroy - every .so file have
simlink in %_libdir/ocaml/site-lib/, while the other library stuff
located in the separate directory.


-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven Luther]

On Wed, May 15, 2002 at 09:39:43PM +0400, Vitaly Lugovsky wrote:
> On Wed, 15 May 2002, Sven Luther wrote:
> 
> > > Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> > > (a tool that adds/removes lines from this file) and with Vitaly
> > > Lugovsky's suggestion (multiple configuration files in a directory).
> > 
> > Would you care to argument a bit more about this, apart from the 'it is
> > not the unix way' argument you give below that is.
> > 
> > and BTW, ocaml-ldconf does not really add/remove lines from the
> > /usr/lib/ocaml/ld.conf file, it uses two separate files
> > (/etc/ocaml/ld.conf and /var/lib/ocaml/ld.conf) which are modified and
> > used to generate the /usr/lib/ocaml/ld.conf.
> > 
> > It is a nice concept (even if it is me saying it) that clearly separate
> > the system administrator stuff (/etc/ocaml/ld.conf) from the
> > dpkg/rpm/whatever handled stuff (/var/lib/ocaml/ld.conf), with the
> > former taking precedence over the later. In no way does it modify the
> > way ocaml handles this, and is thus a purely external tool doing its
> > jjob correctly.
> 
>  This concept looks like ls-R file in the teTeX distribution. And all
> packagers knows that this file is quite a problem. So, as for me,

Would you elaborate more on said problems ?
It is a bit different though, altough i see why you say it is similar.

> I choosed the way suggested by Xavier Leroy - every .so file have
> simlink in %_libdir/ocaml/site-lib/, while the other library stuff
> located in the separate directory.

Ok, if we go that way, it is okay by me, just a decision should be
taken, after a reasoned discussion, and after that we should stick to
it.

That said, i _don't like_ the symlink idea, symlink are a nice thing,
but mainly in this kind of cases are used when you don't have an
integrated distribution, and no packaging system, and many people also
claim that symlink can cause lot of problems. It is more a workaround
for case where you cannot do things properly.

Then if we go that way (all stub libraries in one or two dirs), what
will happen, as far as debian and maybe other integrated distribution
are concerned, is that we will put the stub libraries in the directory
(/usr/lib/ocaml/shlibs or something such), and the rest of the stuff in
the subdirectory. There will be no symlink, and this needs a redesign of
the build process of all those libraries, an adaptation to things like
findlib and ocamlmakefile, and is quite big work, so best to do it for
after there is a final decision on the subject.

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Vitaly Lugovsky]

On Thu, 16 May 2002, Sven Luther wrote:

> >  This concept looks like ls-R file in the teTeX distribution. And all
> > packagers knows that this file is quite a problem. So, as for me,
> 
> Would you elaborate more on said problems ?
> It is a bit different though, altough i see why you say it is similar.

 In general, it's not a good idea to allow packages to modify 
file (not claimed as 'configuration' file) belonging to the other package.
It's an installation sequence problem (it's not specified when you're
installing a lot of packages in one time), it's a security problem
(some may want to have a partical ownership/rights for such a file,
which will be broken by that %post and %preun scripts). And, at last,
it's not a modular approach. It's not a good idea to mix a configuration
and a cache.

> > I choosed the way suggested by Xavier Leroy - every .so file have
> > simlink in %_libdir/ocaml/site-lib/, while the other library stuff
> > located in the separate directory.
> 
> Ok, if we go that way, it is okay by me, just a decision should be
> taken, after a reasoned discussion, and after that we should stick to
> it.

 Sure. But distribution packagers, like me, can't wait for
such a decision. :(

 And, one more thing we have to keep in mind:
it will be very nice to have a possibility to split ocaml libraries
into runtime and development parts. Dynamic libraries belongs to the
runtime part, and, then,  should be handled in an OS native way.
For Unices it's a libraries located in one big pile like /usr/lib/

> That said, i _don't like_ the symlink idea, symlink are a nice thing,
> but mainly in this kind of cases are used when you don't have an
> integrated distribution, and no packaging system, and many people also
> claim that symlink can cause lot of problems. It is more a workaround
> for case where you cannot do things properly.

 But this way is native for unices. It's generally used when you have
different versions of libraries, and so on (see GNU libtool naming
scheme for example).

> 
> Then if we go that way (all stub libraries in one or two dirs), what
> will happen, as far as debian and maybe other integrated distribution
> are concerned, is that we will put the stub libraries in the directory
> (/usr/lib/ocaml/shlibs or something such), and the rest of the stuff in
> the subdirectory. There will be no symlink, and this needs a redesign of
> the build process of all those libraries, an adaptation to things like
> findlib and ocamlmakefile, and is quite big work, so best to do it for
> after there is a final decision on the subject.

 We can't avoid that redesign. Especially if we really want to split runtime
and development parts. This will become a pain when OCaml will be able
to produce a real dynamic native libraries.
 

-------------------
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

Re: [Caml-list] OCaml packaging problems

[Stefano Zacchiroli]

On Thu, May 16, 2002 at 02:24:49PM +0400, Vitaly Lugovsky wrote:
>  Sure. But distribution packagers, like me, can't wait for
> such a decision. :(

Indeed: with debian we choose a solution to the problem because no one
proposed a standard policy. Now seems that a policy is just to be
issued, well for us, we are only asking to take _one_, _definitely_
decision.

> it will be very nice to have a possibility to split ocaml libraries
> into runtime and development parts. Dynamic libraries belongs to the

Already done in debian packages, for each package that ships a library
that contain shared objects we have two packages: one named libfoo-ocaml
and one named libfoo-ocaml-devel where 'foo' is the name of the library.
The former contains the shared objects, the latter contains all the
other developmente stuff.

> runtime part, and, then,  should be handled in an OS native way.
> For Unices it's a libraries located in one big pile like /usr/lib/

Yes, but not /usr/lib itself, something like /usr/lib/ocaml (what a
coincidence! :-) is better, anyway we have a polluted /usr/lib/ocaml
directory so that is better to choose something different like
/usr/lib/ocaml/shlibs or similar. See FHS for more details.

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"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
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven Luther]

On Thu, May 16, 2002 at 02:24:49PM +0400, Vitaly Lugovsky wrote:
> On Thu, 16 May 2002, Sven Luther wrote:
> 
> > >  This concept looks like ls-R file in the teTeX distribution. And all
> > > packagers knows that this file is quite a problem. So, as for me,
> > 
> > Would you elaborate more on said problems ?
> > It is a bit different though, altough i see why you say it is similar.
> 
>  In general, it's not a good idea to allow packages to modify 
> file (not claimed as 'configuration' file) belonging to the other package.
> It's an installation sequence problem (it's not specified when you're
> installing a lot of packages in one time), it's a security problem
> (some may want to have a partical ownership/rights for such a file,
> which will be broken by that %post and %preun scripts). And, at last,
> it's not a modular approach. It's not a good idea to mix a configuration
> and a cache.

Mmm, will look into it, so you are saying to me that there could be
problem when multiple users are running ocaml-ldconf at the same time ? 

I don't really think that is so, but i will look more into it.

1) for package installs, dpkg ensures that only one dpkg is running at
any time and that there is only one package being configured at the same
time.

2) you need to be root to run ocaml-ldconf, so i think, security wise,
there are a lot more thing to worry about if it is not you that have
control on things, and if you do, i suppose you would not install two
libraries at the same time ?


But then, maybe i am not understanding you right, or you are speaking
about a user modifiable config file ?

> > > I choosed the way suggested by Xavier Leroy - every .so file have
> > > simlink in %_libdir/ocaml/site-lib/, while the other library stuff
> > > located in the separate directory.
> > 
> > Ok, if we go that way, it is okay by me, just a decision should be
> > taken, after a reasoned discussion, and after that we should stick to
> > it.
> 
>  Sure. But distribution packagers, like me, can't wait for
> such a decision. :(

Well, not sure, we decided on a course back then in january, and
implemented it, now it turns out that we should have taken a different
approach (since Xavier suggests it).

Ideally there would be a strong policy document on such things.

>  And, one more thing we have to keep in mind:
> it will be very nice to have a possibility to split ocaml libraries
> into runtime and development parts. Dynamic libraries belongs to the

Ok, we have done that for debian, there is a libzip-ocaml package for
example, that contains only the dll, and there is a libzip-ocaml-dev
package that contains the rest of it, provides camlzip for backward
compatibility  and is built from the same source.

No major problem here (apart from a long flamewart on the choosing of
the name scheme).

> runtime part, and, then,  should be handled in an OS native way.
> For Unices it's a libraries located in one big pile like /usr/lib/

Not sure if this zould be the real solution, since the dlls are handled
in a something different way than normal unix C libs. (well in the way
ocamlc and ocamlrun uses them maybe ?)

> > That said, i _don't like_ the symlink idea, symlink are a nice thing,
> > but mainly in this kind of cases are used when you don't have an
> > integrated distribution, and no packaging system, and many people also
> > claim that symlink can cause lot of problems. It is more a workaround
> > for case where you cannot do things properly.
> 
>  But this way is native for unices. It's generally used when you have
> different versions of libraries, and so on (see GNU libtool naming
> scheme for example).

Ocaml doesbn't support versioning anyway, and there is no real need for
it.

And even if it is used, it can cause also a lot of trouble, so if you
don't need it, better avoid it.

> > Then if we go that way (all stub libraries in one or two dirs), what
> > will happen, as far as debian and maybe other integrated distribution
> > are concerned, is that we will put the stub libraries in the directory
> > (/usr/lib/ocaml/shlibs or something such), and the rest of the stuff in
> > the subdirectory. There will be no symlink, and this needs a redesign of
> > the build process of all those libraries, an adaptation to things like
> > findlib and ocamlmakefile, and is quite big work, so best to do it for
> > after there is a final decision on the subject.
> 
>  We can't avoid that redesign. Especially if we really want to split runtime
> and development parts. This will become a pain when OCaml will be able
> to produce a real dynamic native libraries.

Yes, the more reason that a firm and concerted decision is taken, and
then that we don't stray from it.

BTW, what distribution do you represent and how many ocaml packages and
libs do you maintain ?

Friendly,

Sven Luther
>  
> 
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Vitaly Lugovsky]

On Fri, 17 May 2002, Sven Luther wrote:

> >  In general, it's not a good idea to allow packages to modify 
> > file (not claimed as 'configuration' file) belonging to the other package.
> > It's an installation sequence problem (it's not specified when you're
> > installing a lot of packages in one time), it's a security problem
> > (some may want to have a partical ownership/rights for such a file,
> > which will be broken by that %post and %preun scripts). And, at last,
> > it's not a modular approach. It's not a good idea to mix a configuration
> > and a cache.
> 
> Mmm, will look into it, so you are saying to me that there could be
> problem when multiple users are running ocaml-ldconf at the same time ? 

 No. First problem is that package could be installed BEFORE the package
it depends on, and, so, the file will not be updated. I don't know
is it apt-rpm bug or a general rpm feature, but I've noticed this behavior
a few times. And another one problem is that update script must be started
by the configuration file owner, which is a potential security hole.

> I don't really think that is so, but i will look more into it.

 And, sure, there could be some problems with blocking. But I did not
considered this yet.

> 1) for package installs, dpkg ensures that only one dpkg is running at
> any time and that there is only one package being configured at the same
> time.

 And the same for rpm. But we may have a local packages as well, installed
without packaging system. It's a pain with only one global configuration
file.

> 2) you need to be root to run ocaml-ldconf, so i think, security wise,
> there are a lot more thing to worry about if it is not you that have
> control on things, and if you do, i suppose you would not install two
> libraries at the same time ?

 Sure. But we have only one configuration file, not a list of files with
different permissions and priorities. And so, localy installed libraries
goes there as well. And, again, we must install the package owning that
configuration file while we only want to use some applications and runtime
libraries used by them, which is not a good approach.

> But then, maybe i am not understanding you right, or you are speaking
> about a user modifiable config file ?

 Since we have only one config file, without local and per-user modules,
this one should be user-modifiable. Or we have to invent a more modular
and secure approach. As well as I'm dreaming about having alternative
locations of texmf tree with their own ls-R configs.

> >  Sure. But distribution packagers, like me, can't wait for
> > such a decision. :(
> 
> Well, not sure, we decided on a course back then in january, and
> implemented it, now it turns out that we should have taken a different
> approach (since Xavier suggests it).
> 
> Ideally there would be a strong policy document on such things.

 Sure. But this policy must be secure and flexible enough not to conflict
with partial distributions policies.

> >  And, one more thing we have to keep in mind:
> > it will be very nice to have a possibility to split ocaml libraries
> > into runtime and development parts. Dynamic libraries belongs to the
> 
> Ok, we have done that for debian, there is a libzip-ocaml package for
> example, that contains only the dll, and there is a libzip-ocaml-dev
> package that contains the rest of it, provides camlzip for backward
> compatibility  and is built from the same source.
> 
> No major problem here (apart from a long flamewart on the choosing of
> the name scheme).

 May be there's no problem, but how do you handle dll paths without
that config file belonging to ocaml package? I can't check out Debian
approach now due to the problems with internet connection :(

> > runtime part, and, then,  should be handled in an OS native way.
> > For Unices it's a libraries located in one big pile like /usr/lib/
> 
> Not sure if this zould be the real solution, since the dlls are handled
> in a something different way than normal unix C libs. (well in the way
> ocamlc and ocamlrun uses them maybe ?)

 I can't see the difference. Can you explain it?

> >  But this way is native for unices. It's generally used when you have
> > different versions of libraries, and so on (see GNU libtool naming
> > scheme for example).
> 
> Ocaml doesbn't support versioning anyway, and there is no real need for
> it.

 As well as C. Version is just a part of the library name. So, we can
have different versions of the library in the same directory, with
different applications linked with all that versions without conflicts.
It's not a language-specific matter at all.

> And even if it is used, it can cause also a lot of trouble, so if you
> don't need it, better avoid it.

 It can't cause troubles. But the lack of this feature can. Don't you
remember all that Windows pain with DLLs?

> BTW, what distribution do you represent and how many ocaml packages and
> libs do you maintain ?

 ALT Linux. It's a russian distribution formerly based on Mandrake, but
evolved then to the completely new base. It's working over apt-rpm port.
Now I packaged some findlib-based libs, lablGL, lablgtk, camlimages,
camltk, and so on - the things I'm using myself. And I can't move forward
until the clear library packaging approach is choosed. :(

-------------------
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

Re: [Caml-list] OCaml packaging problems

[Michal Moskal]

On Fri, May 17, 2002 at 11:31:37PM +0400, Vitaly Lugovsky wrote:
> On Fri, 17 May 2002, Sven Luther wrote:
> > Mmm, will look into it, so you are saying to me that there could be
> > problem when multiple users are running ocaml-ldconf at the same time ? 
> 
>  No. First problem is that package could be installed BEFORE the package
> it depends on, and, so, the file will not be updated. I don't know
> is it apt-rpm bug or a general rpm feature, but I've noticed this behavior
> a few times. And another one problem is that update script must be started
> by the configuration file owner, which is a potential security hole.

General rpm feature. Use PreReq: instead of Requires: to get package
always installed after the package it depends.

> > 1) for package installs, dpkg ensures that only one dpkg is running at
> > any time and that there is only one package being configured at the same
> > time.
> 
>  And the same for rpm. But we may have a local packages as well, installed
> without packaging system. It's a pain with only one global configuration
> file.

For PLD Linux I have choosen to have only /usr/lib/ocaml in ld.conf and
have symlinks to dll*so there, just beacuse I thought it is simplest
approach. You can check http://www.pld-linux.org/ocaml.html for details.
(BTW: nice document about Debian OCaml packaging policy can be found in
Debian ocaml package).

Of course if there are local libraries, say in /usr/local/lib/ocaml user
is free to add anything to ld.conf, this scheme depends only on
/usr/lib/ocaml presence there.

> > >  But this way is native for unices. It's generally used when you have
> > > different versions of libraries, and so on (see GNU libtool naming
> > > scheme for example).
> > 
> > Ocaml doesbn't support versioning anyway, and there is no real need for
> > it.
> 
>  As well as C. Version is just a part of the library name. So, we can
> have different versions of the library in the same directory, with
> different applications linked with all that versions without conflicts.
> It's not a language-specific matter at all.

There might be problem with check sums of interfaces. OCaml is far more 
restrictive when it comes to ABI compatibility then C. This probably
isn't so problematic with dll*.so files (as they do not tend to change), 
but it will be, when native code libraries could be placed in shared
files.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven Luther]

On Fri, May 17, 2002 at 11:31:37PM +0400, Vitaly Lugovsky wrote:
> On Fri, 17 May 2002, Sven Luther wrote:
> 
> > >  In general, it's not a good idea to allow packages to modify 
> > > file (not claimed as 'configuration' file) belonging to the other package.
> > > It's an installation sequence problem (it's not specified when you're
> > > installing a lot of packages in one time), it's a security problem
> > > (some may want to have a partical ownership/rights for such a file,
> > > which will be broken by that %post and %preun scripts). And, at last,
> > > it's not a modular approach. It's not a good idea to mix a configuration
> > > and a cache.
> > 
> > Mmm, will look into it, so you are saying to me that there could be
> > problem when multiple users are running ocaml-ldconf at the same time ? 
> 
>  No. First problem is that package could be installed BEFORE the package

This should not be hapenning, it probably is a bug in your package
handler. Not sure though.

What can happen is that both package are installed first, and then only
configured, altough this late one will probably still be done in the
dependency order.

> it depends on, and, so, the file will not be updated. I don't know
> is it apt-rpm bug or a general rpm feature, but I've noticed this behavior
> a few times. And another one problem is that update script must be started
> by the configuration file owner, which is a potential security hole.

Well, it mostly is run by root, and so i guess this is a problem when
you don't trust the packager. This is where debian's large web of truce
and big number of packaged programs help a lot :)))

> > I don't really think that is so, but i will look more into it.
> 
>  And, sure, there could be some problems with blocking. But I did not
> considered this yet.

Mmm, ...

> > 1) for package installs, dpkg ensures that only one dpkg is running at
> > any time and that there is only one package being configured at the same
> > time.
> 
>  And the same for rpm. But we may have a local packages as well, installed
> without packaging system. It's a pain with only one global configuration
> file.

Well, not really, since upto now, they were handled in a separate file
(/etc/ocaml/ld.conf) and even if you install them at the same time as
you upgrade the system, it will only be broken until you next upgrade
an ocaml package (and even then, its your own fault for messing things
up).
> 
> > 2) you need to be root to run ocaml-ldconf, so i think, security wise,
> > there are a lot more thing to worry about if it is not you that have
> > control on things, and if you do, i suppose you would not install two
> > libraries at the same time ?
> 
>  Sure. But we have only one configuration file, not a list of files with
> different permissions and priorities. And so, localy installed libraries

Mmm, we have two for debian, /etc/ocaml/ld.conf for the locally
installed files, and /var/lib/ocaml/ld.conf for the dpkg handled ones.
The first one will never be touched by ocmal-ldconf, and so there is no
big risk about it.

The only problem i have right now, is that locally installed files want
to write to /usr/lib/ocaml/ld.conf, which is overwritten by a next run
to ocaml-ldconf, i will be changing this in the next release of an ocaml
debian package. There are two ways of doing this, making
/usr/lib/ocaml/ld.conf readonly, so people running local installs will
read it, and patching ocaml so it uses a /usr/lib/ocaml/debina_ld.conf
or something such, and have /usr/lib/ocaml/ld.conf be a symlink to
/etc/ocaml/ld.conf (which is a much more appropriate choice for this
kind of thing, and policy compliant to boost. It would be nice if ocaml
3.05 would allow an easy configuration of the position of this file, as
well as a option to ocaml that give this path back, in order for install
systems to cope with non standard places.

> goes there as well. And, again, we must install the package owning that
> configuration file while we only want to use some applications and runtime
> libraries used by them, which is not a good approach.

Yes, maybe it would be ok to consider ta ~/.ocaml/ld.conf file ?

> > But then, maybe i am not understanding you right, or you are speaking
> > about a user modifiable config file ?
> 
>  Since we have only one config file, without local and per-user modules,

Yes, i understand, we have two, so the problem is not so big, altough
there are other problems, like the ones mentioned above, and the fact
that you have to run ocaml-ldconf after modifying the local ld.conf
databas (like it is done for the C /etc/ld.conf). If ocaml-ldconf was
part of the upstream ocaml, it would make things easier.

> this one should be user-modifiable. Or we have to invent a more modular
> and secure approach. As well as I'm dreaming about having alternative
> locations of texmf tree with their own ls-R configs.

Mmm, my understanding was that users should use some other kind of trick
for playing with dlls, not the ld.conf ones, especially if he is not
root, unless it is a local ocaml install that is.

> > >  Sure. But distribution packagers, like me, can't wait for
> > > such a decision. :(
> > 
> > Well, not sure, we decided on a course back then in january, and
> > implemented it, now it turns out that we should have taken a different
> > approach (since Xavier suggests it).
> > 
> > Ideally there would be a strong policy document on such things.
> 
>  Sure. But this policy must be secure and flexible enough not to conflict
> with partial distributions policies.

huh ???

What parital distributions policies are you speaking about ?

> > >  And, one more thing we have to keep in mind:
> > > it will be very nice to have a possibility to split ocaml libraries
> > > into runtime and development parts. Dynamic libraries belongs to the
> > 
> > Ok, we have done that for debian, there is a libzip-ocaml package for
> > example, that contains only the dll, and there is a libzip-ocaml-dev
> > package that contains the rest of it, provides camlzip for backward
> > compatibility  and is built from the same source.
> > 
> > No major problem here (apart from a long flamewart on the choosing of
> > the name scheme).
> 
>  May be there's no problem, but how do you handle dll paths without
> that config file belonging to ocaml package? I can't check out Debian

There is a ocaml-base package, which has only the dlls of the ocaml core
distribution, the ld.conf files (mmm, maybe not even them) and the
ocaml-ldconf executable.

Each ocaml related package which has dlls is calling at postinst and
prerm the ocaml-ldconf file, which adds or removes a path/package line
in the /var/lib/ocaml/ld.conf file, and then regenerates the
/usr/lib/ocaml/ld.conf file from this file and the /etc/ocaml/ld.conf
one.

If one of these files does not exist yet, they get created by the
ocaml-ldconf program. I don't remember out of hand, but i guess they are
also marked as conffiles, at least the /etc/ocaml/ld.conf one is.

> approach now due to the problems with internet connection :(

:)))

> 
> > > runtime part, and, then,  should be handled in an OS native way.
> > > For Unices it's a libraries located in one big pile like /usr/lib/
> > 
> > Not sure if this zould be the real solution, since the dlls are handled
> > in a something different way than normal unix C libs. (well in the way
> > ocamlc and ocamlrun uses them maybe ?)
> 
>  I can't see the difference. Can you explain it?

Well, they are only used by ocamlrun and ocamlc and co, not by any
external program.

> 
> > >  But this way is native for unices. It's generally used when you have
> > > different versions of libraries, and so on (see GNU libtool naming
> > > scheme for example).
> > 
> > Ocaml doesbn't support versioning anyway, and there is no real need for
> > it.
> 
>  As well as C. Version is just a part of the library name. So, we can
> have different versions of the library in the same directory, with
> different applications linked with all that versions without conflicts.
> It's not a language-specific matter at all.

Well, previous discution here had me convinced that versioning would
involve non trivial type checking for incompatible module interfaces or
something such (not the best explanation, so please look at that huge
thread youself).

The basic idea was that if you were going to do versioning, let's do it
right, and not like it is done in C, and that doing it right is not an
easy thing.

> > And even if it is used, it can cause also a lot of trouble, so if you
> > don't need it, better avoid it.
> 
>  It can't cause troubles. But the lack of this feature can. Don't you

Sure, just imagine someone changes the interface without bumping the
major version number, or that some of the symlinks got broken badly by a
mix of hand and automated isntalls (not to speak about a broken
package), and things will break some, don't you think.

> remember all that Windows pain with DLLs?

No, i never run windows if i can avoid it :)))

> > BTW, what distribution do you represent and how many ocaml packages and
> > libs do you maintain ?
> 
>  ALT Linux. It's a russian distribution formerly based on Mandrake, but

Ok, i didn't know of you. Please feel free to subscribe to the
debian-ocaml-maint mailing list, where we discuss things related to
package maintenance of ocaml related packages. It is debian specific,
but many things may not be, and i think we will be happy to have you
there (well as the list moderator, i am inviting and welcoming you).

> evolved then to the completely new base. It's working over apt-rpm port.
> Now I packaged some findlib-based libs, lablGL, lablgtk, camlimages,
> camltk, and so on - the things I'm using myself. And I can't move forward

Same for me, (altough i don't do findlib myself, i never use it). BTW,
did you resolve the problem of camltk not being dll ready ?

> until the clear library packaging approach is choosed. :(

Well, ok, i see your point. We decided to choose a solution that worked
ok for us, and i did implement it. Now, it appears upstream as choosen
another approach, but debian woody will chip (any day now) with the
current situation of using two databases and ocaml-ldconf.

Friendly,

Sven Luther
> 
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven Luther]

On Tue, May 14, 2002 at 10:54:52AM +0200, Xavier Leroy wrote:
> So, to summarize, I strongly suggest the following approach for RPMs
> or Debian packages:
> - The main Caml package can add one or two lines to ld.conf,
>   e.g. /var/lib/ocaml/shlibs (for libraries installed by other packages)
>   and /usr/local/lib/ocaml/shlibs (for local stuff)
> - Packages for additional Caml libraries install their shared libraries
>   in /var/lib/ocaml/shlibs, either directly or via a symlink.

Xavier, ...

I am going to prepare a new ocaml debian package which will support what
you suggest, but still be compatible with the current way of doing
things (using the external ocaml-ldconf program).

What i will do is have the ocaml-base package (which contains the
minimum needed to run bytecode programs only, namely ocamlrun and the
dll.so) add /usr/lib/ocaml/shlibs for stub libraries provided by a
debian package, and /usr/local/lib/ocaml/shlibs for stub libraries
provided by third party libraries.

Debian packaged library will move the dll.so into these directories, and
everything will be fine, but older packages or packages with lazy
maintainers will still be able to use ocaml-ldconf.

Third parties libraries (that is, non debian packaged ones) which use findlib
will know about this scheme, and use the debian package version of findlib to
install stuff in the proper place (/usr/local/lib/ocaml/shlibs).

Third party libraries which do not use findlib, either don't know about
dll.so, and in this case there is no problem, or try to install them
either in /usr/lib/ocaml (which is bad) or add a file by hand into
/usr/lib/ocaml/ld.conf.

In this later case, i will try to prevent this from happening, and make
people aware that this is not the correct way of doing this (if we agree
on that, that is).

But there are two points i much would like a consensus being attained on
:

1)  What will be the exact name of these directories ? It would be a good
idea, i think at least, if we choose the same name for all
installations of ocaml, and not everyone choosing it's own directory.
(or else we could have a ocaml option similar to -where which would
give a pointer to these directories ? and have the choice of the
directory highly configurable, maybe a -where_stub or something such ?)

Actually i have the proposition of "shlibs" from you, and "libexec" from
Gerd and the findlib people. and then i feel myself "stublibs" should be
a nice name too, especially since it is just the sub libraries we are
speaking about, and not the .cma and other such ocaml libraries.

2) I think it would be nice to distinguish two such directories,
/usr/lib/ocaml/shlibs for distribution native libraries (the packaged
ones that follow the rule), and /usr/local/lib/ocaml/shlibs for hand
installed packages. What precedence should we take for them by default ?

And should these two dirs be hardcoded into the ocaml suite, (as are
/usr/lib and /lib into the C ld.so) ?

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Xavier Leroy]

> I am going to prepare a new ocaml debian package which will support what
> you suggest, but still be compatible with the current way of doing
> things (using the external ocaml-ldconf program).
> [description omitted]

Looks good.  

> But there are two points i much would like a consensus being attained on :
> 
> 1)  What will be the exact name of these directories ? It would be a good
> idea, i think at least, if we choose the same name for all
> installations of ocaml, and not everyone choosing it's own directory.
> (or else we could have a ocaml option similar to -where which would
> give a pointer to these directories ? and have the choice of the
> directory highly configurable, maybe a -where_stub or something such ?)
> 
> Actually i have the proposition of "shlibs" from you, and "libexec" from
> Gerd and the findlib people. and then i feel myself "stublibs" should be
> a nice name too, especially since it is just the sub libraries we are
> speaking about, and not the .cma and other such ocaml libraries.

My proposal for "shlibs" was just for the sake of example, and isn't
very descriptive.  I like "stublibs" or "libexec" better, actually.

> 2) I think it would be nice to distinguish two such directories,
> /usr/lib/ocaml/shlibs for distribution native libraries (the packaged
> ones that follow the rule), and /usr/local/lib/ocaml/shlibs for hand
> installed packages.

Keep in mind that there is only one OCaml standard library directory.
So, non-packaged libraries tend to install in `ocamlc -where`/LIBNAME,
and would put their DLLs in `ocamlc -where`/stublibs.  Hence,
I'm not sure the second directory /usr/local/lib/ocaml/stublibs
would be used a lot.  But it doesn't hurt.

On a related issue, to facilitate the transition from the current
scheme, it might be worth adding /usr/lib/ocaml as a third
directory, at least for the next two releases or so.

> And should these two dirs be hardcoded into the ocaml suite, (as are
> /usr/lib and /lib into the C ld.so) ?

I don't think so.  The hardcoding in ld.so seems to come from a desire
to facilitate disaster recovery: even if the ld.so cache or
configuration files get accidentally wiped, a reasonable number of
dynamically-linked utility programs still run.  There is less to worry
about wiping OCaml's ld.conf file.

- Xavier Leroy
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven Luther]

On Tue, Jun 18, 2002 at 02:57:33PM +0200, Xavier Leroy wrote:
> > I am going to prepare a new ocaml debian package which will support what
> > you suggest, but still be compatible with the current way of doing
> > things (using the external ocaml-ldconf program).
> > [description omitted]
> 
> Looks good.  

:)))

> > But there are two points i much would like a consensus being attained on :
> > 
> > 1)  What will be the exact name of these directories ? It would be a good
> > idea, i think at least, if we choose the same name for all
> > installations of ocaml, and not everyone choosing it's own directory.
> > (or else we could have a ocaml option similar to -where which would
> > give a pointer to these directories ? and have the choice of the
> > directory highly configurable, maybe a -where_stub or something such ?)
> > 
> > Actually i have the proposition of "shlibs" from you, and "libexec" from
> > Gerd and the findlib people. and then i feel myself "stublibs" should be
> > a nice name too, especially since it is just the sub libraries we are
> > speaking about, and not the .cma and other such ocaml libraries.
> 
> My proposal for "shlibs" was just for the sake of example, and isn't
> very descriptive.  I like "stublibs" or "libexec" better, actually.

I would go for stublibs myself, but the findlib folk seems keen on
libexec. Maybe we should have a long discution here on that, or you
would decide and we keep that, i don't know, i would need more opinion
on this.

> > 2) I think it would be nice to distinguish two such directories,
> > /usr/lib/ocaml/shlibs for distribution native libraries (the packaged
> > ones that follow the rule), and /usr/local/lib/ocaml/shlibs for hand
> > installed packages.
> 
> Keep in mind that there is only one OCaml standard library directory.
> So, non-packaged libraries tend to install in `ocamlc -where`/LIBNAME,
> and would put their DLLs in `ocamlc -where`/stublibs.  Hence,
> I'm not sure the second directory /usr/local/lib/ocaml/stublibs
> would be used a lot.  But it doesn't hurt.

Yes, altough findlib seems to be able to know about it and install thing
in /usr/local/lib, if we need to.

> On a related issue, to facilitate the transition from the current
> scheme, it might be worth adding /usr/lib/ocaml as a third
> directory, at least for the next two releases or so.

We will keep the full separate directory stuff active in the meantime,
/usr/lib/ocaml is one of those dirs anyway, so there should be no
problem.

> > And should these two dirs be hardcoded into the ocaml suite, (as are
> > /usr/lib and /lib into the C ld.so) ?
> 
> I don't think so.  The hardcoding in ld.so seems to come from a desire
> to facilitate disaster recovery: even if the ld.so cache or
> configuration files get accidentally wiped, a reasonable number of
> dynamically-linked utility programs still run.  There is less to worry
> about wiping OCaml's ld.conf file.

Ok, ...

But then, i would argue for some more switch for ocaml (an ocamlc
-wherestubs or even a ocamlc -wherelocal) so that installation programs
not using findlib can have a greater control on where to install their
stuff.

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Gerd Stolpmann]

On 2002.06.18 15:32 Sven Luther wrote:
> On Tue, Jun 18, 2002 at 02:57:33PM +0200, Xavier Leroy wrote:
> > > 1)  What will be the exact name of these directories ? It would be a good
> > > idea, i think at least, if we choose the same name for all
> > > installations of ocaml, and not everyone choosing it's own directory.
> > > (or else we could have a ocaml option similar to -where which would
> > > give a pointer to these directories ? and have the choice of the
> > > directory highly configurable, maybe a -where_stub or something such ?)
> > > 
> > > Actually i have the proposition of "shlibs" from you, and "libexec" from
> > > Gerd and the findlib people. and then i feel myself "stublibs" should be
> > > a nice name too, especially since it is just the sub libraries we are
> > > speaking about, and not the .cma and other such ocaml libraries.
> > 
> > My proposal for "shlibs" was just for the sake of example, and isn't
> > very descriptive.  I like "stublibs" or "libexec" better, actually.
> 
> I would go for stublibs myself, but the findlib folk seems keen on
> libexec. Maybe we should have a long discution here on that, or you
> would decide and we keep that, i don't know, i would need more opinion
> on this.

There is no traditional name for the directory containing dynamically loaded 
libraries, i.e. libraries that are not linked with "-l" into the executable.
"libexec" is intended for executables that are run as a result of library
calls, and that are not in PATH. I chose "libexec" because that was most
close to DLLs.

I don't know if this is a good name, however, and I can change it again in 
the findlib distribution. I think the point is whether everybody familiar
with filesystem conventions finds the DLL directory immediately.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Sven Luther]

On Tue, Jun 18, 2002 at 10:04:02PM +0200, Gerd Stolpmann wrote:
> 
> On 2002.06.18 15:32 Sven Luther wrote:
> > On Tue, Jun 18, 2002 at 02:57:33PM +0200, Xavier Leroy wrote:
> > > > 1)  What will be the exact name of these directories ? It would be a good
> > > > idea, i think at least, if we choose the same name for all
> > > > installations of ocaml, and not everyone choosing it's own directory.
> > > > (or else we could have a ocaml option similar to -where which would
> > > > give a pointer to these directories ? and have the choice of the
> > > > directory highly configurable, maybe a -where_stub or something such ?)
> > > > 
> > > > Actually i have the proposition of "shlibs" from you, and "libexec" from
> > > > Gerd and the findlib people. and then i feel myself "stublibs" should be
> > > > a nice name too, especially since it is just the sub libraries we are
> > > > speaking about, and not the .cma and other such ocaml libraries.
> > > 
> > > My proposal for "shlibs" was just for the sake of example, and isn't
> > > very descriptive.  I like "stublibs" or "libexec" better, actually.
> > 
> > I would go for stublibs myself, but the findlib folk seems keen on
> > libexec. Maybe we should have a long discution here on that, or you
> > would decide and we keep that, i don't know, i would need more opinion
> > on this.
> 
> There is no traditional name for the directory containing dynamically loaded 
> libraries, i.e. libraries that are not linked with "-l" into the executable.
> "libexec" is intended for executables that are run as a result of library
> calls, and that are not in PATH. I chose "libexec" because that was most
> close to DLLs.
> 
> I don't know if this is a good name, however, and I can change it again in 
> the findlib distribution. I think the point is whether everybody familiar
> with filesystem conventions finds the DLL directory immediately.

Well, let's all together choose a name and make it the 'traditional' name for
everyone.

There are two points to consider here :

 1) right now, the only thing we will put in this directory are stub
    libraries that are supposed to be dynamically loaded (the
    dllxxx.so).
 
    => so stublibs or dlls or something such is a good name, I think in
    this approach, stublib is a good name, since it distinguish between
    the stub libraries and the other libraries (well either the C libs
    (in /usr/lib) or the ocaml .cma (in /usr/lib/ocaml and its sublibs.

 2) In the future, more stuff may benefit from this same dynamic loading
    mechanism, which will not necessarily be only the stub libraries. If
    this happen to be the case, we will not want to change the name
    later on, and should choose a more generic name.

    => dlls, or dynlibs or something such would be a good choice here,
    but the real question is to know if this is something that may
    happen in the future or not.

Thus, myself i would choose between :

  o /usr/lib/ocaml/stublibs if we will only ever put stub libs in this
    directory.

  o /usr/lib/ocaml/dynlibs if we will later on also put other libs in this
    directory.

But then, we could have a multiple directories layout, with one being
for stublibs, and others for other kind of dynamic loading libs (or .cma),
So i would go with stublibs.

Are there comments on this, or can i go ahead with this ?

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] OCaml packaging problems

[Markus Mottl]

On Wed, 19 Jun 2002, Sven Luther wrote:
> Thus, myself i would choose between :
> 
>   o /usr/lib/ocaml/stublibs if we will only ever put stub libs in this
>     directory.
> 
>   o /usr/lib/ocaml/dynlibs if we will later on also put other libs in this
>     directory.
> 
> But then, we could have a multiple directories layout, with one being
> for stublibs, and others for other kind of dynamic loading libs (or .cma),
> So i would go with stublibs.

"stublibs" sounds reasonable to me.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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