On Fri, Sep 06, 2002 at 04:59:14PM +0200, Stefano Zacchiroli wrote: > On Fri, Sep 06, 2002 at 04:25:13PM +0200, Sven LUTHER wrote: > > 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. > > Ok: > decr problems;;
:))) But it is just an hacky solution, there must be somewhat more elegant, maybe ... > > 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. > > Ok, I've just sent to the BTS the patch for > /usr/share/debhelper/autoscripts/postrm-ocamlld (which is the template > used by debhelper to create the postrm script). Yes, gotten and applied. > [ BTW I've also sent to the BTS the ancient patch for ocaml-ldconf, so > you can see if there is still the case to apply it or not ] you forgot to attach it or something. Note: i also applied the ocaml-source move. > > The --purge should be ok, since it seems to call remove also. > > Right. > > > 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. > > Uhm, I am for a middle-way approach: no matter what we will choose > between the first and second point, my idea is to keep the fix until > woody+1 and then switch to the third point. The user that probably need > the fix after woody+1 are probably ... none ... anyway we can told users > to safely remove path in /var/lib/ocaml/ld.conf if they found it. We could also rename /var/lib/ocaml/ld.conf, and have ocaml-ldconf remove the old /var/lib/ocaml/ld.conf if it is present :))) (it will break installed libs though). > > 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. > > see above. Well, i still think it is something that needs to be around forever. > > What do you think about it, does someone still has the patch about ? (or > > maybe i should upgrade to a newer debhelper). > > sent to the BTS. :))) > > And does someone know if it is easily possible to have dh_ocamlld made > > aware of the -g and -r <version_number> options ? > > Is possible but I think that is an unneeded effort. > > As you said having useless dirs is not too bad, moreover we can remove > it from now until woody+1 manually invoking dh_ocamlld -r .... where > needed, after woody+1 affected systems will be probably none: I don't > like to change dh_ocamlld just for these. Mmm, does adding a dh_ocamlld -r do the thing we want ? I don't think so, we maybe need to call ocaml-ldconf -R -plibname-ocaml explicitly in a hand written postinst, until woody +1. Mmm, if there is no -r <version_number> option that we could pass to dh_ocamlld, then a centralized solution would be better, are you sure you are not saying that so i go for your solution ? :)))) Mmm, maybe i will learn perl finally and write it myself ... Friendly, Sven Luther
