[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: purge_ld_conf.pl [Was: Re: the move to stublib]



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

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

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

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

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

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

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

Attachment: pgpVXcnvfAWkG.pgp
Description: PGP signature


Reply to: