On Mon, Jul 08, 2002 at 10:31:47PM +0200, Stefano Zacchiroli wrote: > Two news: one good and one bad. > > The good one: > > no problem for modification to /etc/ocaml/ld.conf, that was my fault: > I expected /etc/ocaml/ld.conf format to be the same as > /usr/lib/ocaml/ld.conf ... yes I had not read the manpage of > ocaml-ldconf :-((( > > Anyway to avoid others' lazyness mistake I suggest to patch > ocaml-ldconf so that it output a warning or an error message if > /etc/ocaml/ld.conf isn't in the expected format.
Well, what did you put in /etc/ocaml/ld.conf for the package name ? Also i will add the syntax of just a lone dir as synomyn to dir add. > The bad one: > > the upgrading problem is real and is a bug in dh_ocamlld (I'm going to > submit the bug just after this mail): while upgrading to a new package > version, "postrm" script is invoked with "upgrade" argument (in $1), > while dh_ocamlld generated postrm will check only for "remove" > argument so that if you remove a package, the path is removed from > /var/lib/ocaml/ld.conf, if you upgrade the package to a version that > no longer need that path, the path will remain in > /var/lib/ocaml/ld.conf. This is just the case for all packages that > currently ships private .so dirs and from now on will put shared > objects in /usr/lib/ocaml/stublibs. > > What we can do to purge this dirs? IMO we can patch ocaml-ldconf so > that it remove dirs that contains no shared objects (outputting a > warning) and invoke ocaml-ldconf in postinst script of the new > ocaml package. Probably we can also consider as a special case > stublibs dir, not excluding it even if it contains no shared objects. > Any other idea? Why not hand erase them in the postinst ? Or fix dh_ocamlld ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
