Re: purge_ld_conf.pl [Was: Re: the move to stublib]
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
Reply to: