Re: purge_ld_conf.pl [Was: Re: the move to stublib]
On Fri, Sep 06, 2002 at 02:22:23PM +0200, Stefano Zacchiroli wrote:
> On Fri, Sep 06, 2002 at 11:09:29AM +0200, Sven LUTHER wrote:
> > Anyway, i have here given a good reason for the per package cleanup, and
> > a good reason against it, i think mostly these are the two points we
> > have to weight, other stuff being more due to laziness/hacky solutions.
> >
> > What do you think about it ?
>
> I agree with you that a per package solution is more cleanly, but can be
> a bit overkilling if we have a lot of packages to fix.
> So IMO the final decision point is: "how many packages have we to fix?".
Not so much, only the current libraries, for me it is lablgtk, lablgl,
mlgtk and camlzip.
> Regarding me, I have to fix these packages:
> - camlimages
> - lablgtkmathview
> - pcre
> - shell
There are still many packages around, i think.
> _and_ the new packages of mine that still are using the old library
> schema, because is probably that some user have installed a version made
> with bugged dh_ocamlld.
Well, all currently installed libraries.
> Have we a lot more packages to fix?
>
> BTW, IMO we can keep the fix around only until next major release
> because debian upgrade skipping major release is really an unlikely
> case and after the next major release we are sure (assuming that
> dh_ocamlld is now fixed, right Sven?) that all debian ocaml library
> packages have been built correctly.
Well, right now, we need to handle three class of packages (well, two
library schemes and the ocaml-base case) :
a) old scheme libraries (camlzip for example) which calls :
dh_ocamlld -plibzip-ocaml /usr/lib/ocaml/zip
b) new scheme libraries (mlgtk for example) which calls :
dh_ocamlld -plibzip-ocaml
c) ocaml-base which calls :
dh_ocamlld -pocaml-base
There are two problems, the first, concerning only me and the ocaml-base
package, which i solved by calling ocaml-ldconf in a hand written
postinst, was responsable for the broken /usr/lib/ocaml/ld.conf bug.
The other, is that old scheme libraries fail to remove the libraries
when doing an upgrade (as opposed to a remove, don't know about a
purge).
In fact, camlzip, as built with ocaml 3.06-5 (a local built, not the one
in the archive) yields the following postrm scripts :
$ cat libzip-ocaml.postrm.debhelper
# Automatically added by dh_ocamlld
if [ "$1" = "remove" -a -x /usr/bin/ocaml-ldconf ]; then
/usr/bin/ocaml-ldconf -p libzip-ocaml -r /usr/lib/ocaml/zip
fi
# End automatically added section
And the postrm ocaml-ldconf call will not be called for the upgrade
action. I think i had a patch for this or something such, but it still
is in my dead box HD, and not available right now. This is not fixed,
and need to be.
The --purge should be ok, since it seems to call remove also.
So, no, the problem is not yet fixed (but it will be in the next package
i upload) and it will be a problem for each and every old scheme library
around, as well as for the new scheme libraries which date from before
the fix.
After thinking about it, we can take three attitudes toward this :
o fix this in a centralized way in ocaml-base postinst (with an
upgraded ocaml-ldconf or your script).
o fix this per library.
o don't fix it, and provide a hint for the users to fix this by
themselves.
Notice that in the two first cases, it will be something which we will
need to carry around forever, not just upto the next major release,
since there are also people who will upgrade woody directly to woody+2.
That is another reason we should do this per library, i think, as
ocaml-base as no way to know if this is fixed or not.
Doing this per library would allow us to check for the lastly configured
version (which is in $2), and do the cleanup only if it is lower than a
version provided to the dh_ocamlld script (with the -R option ?).
Newer library, which do not know about the broken dh_ocamlld, can simply
do nothing, or maybe simply add a dh_ocamlld -plibname-ocaml in their
debian/rules.
Notice, the third option (doing nothing) is also valable, since the
paths added by /var/lib/ocaml/ld.conf come _after_ the default ones, and
it would just search a few more path in the unlikely case that you try
loading an unexistent library. It is not that bad.
Changes needed for this scheme to work :
o for old library scheme, we want :
dh_ocamlld -plibzip-ocaml /usr/lib/ocaml/zip
yielding :
- in postinst, a call to :
ocaml-ldconf -plibzip-ocaml -a /usr/lib/ocaml/zip
- in prerm, a call to :
ocaml-ldconf -plibzip-ocaml -r /usr/lib/ocaml/zip
=> As now, but with a fixed dh_ocamlld.
o for new library scheme, we want :
dh_ocamlld -plibmlgtk-ocaml -r _fixed_version_
yielding :
- in postinst, a call to :
if $2 < _provided_version_ then ocaml-ldconf -plibmlgtk-ocaml -R fi
=> this will do nothing if the version is ok, and remove any
reference of the libmlgtk-ocaml package in the
/var/lib/ocaml/ld.conf database.
o for ocaml-base, we want :
dh_ocamlld -pocaml-base -g
- in postinst, a call to :
ocaml-ldconf -pocaml-base
=> With ocaml-ldconf fixed so it ignores the -pocaml-base argument
and generate the database.
I have looked at dh_ocamlld, but it doesn't seem easy (for me, not
speaking perl and all) to have it handle the options needed to handle
this.
What do you think about it, does someone still has the patch about ? (or
maybe i should upgrade to a newer debhelper).
And does someone know if it is easily possible to have dh_ocamlld made
aware of the -g and -r <version_number> options ?
Friendly,
Sven Luther
Reply to: