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

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



On Sun, Sep 08, 2002 at 10:38:48PM +0200, Denis Barbier wrote:
> On Sun, Sep 08, 2002 at 07:00:14PM +0200, Sven LUTHER wrote:
> [...]
> > > Sven, before jumping into details, we should:
> > >   a) define procedures to run on package install and upgrade
> > >   b) find how to implement these procedures without breaking
> > >      installed packages.
> > 
> > Huh ???
> > 
> > > I am at the moment confused by all the recent mails about this issue and
> > > unable to know what you have in mind.
> > 
> > Ok, let me recapitulate this :
> > 
> >   a) Old scheme libraries did add directories to /var/lib/ocaml/ld.conf
> >   during configure and remove them during remove. They failed to remove
> >   dirs during upgrade though.
> > 
> >   b) New scheme libraries put all stublibs in a common place, so no
> >   /var/lib/ocaml/ld.conf entry is needed.
> > 
> >   c) Saddly, due to the fact the old dh_ocamlld forgot to handle the
> >   removal of the directories of /var/lib/ocaml/ld.conf in an upgrade,
> >   the entries did not get removed when switching from a) libraries to b)
> >   libraries.
> > 
> > This last point is what we want to fix.
> 
> But again there are 2 distinct issues:
>   1.  Long term plans for sarge+1

All stublibs go into /usr/lib/ocaml/stublibs, no entry in
/var/lib/ocaml/ld.conf is necessary.

All user installed stublibs go into /usr/local/lib/ocaml/3.06/stublibs,
no entry in /etc/ocaml/ld.conf is necessary.

>   2.  Transition phase

What i propose is the transition phase, to get ride of the packages
which did not cleanup behind them on upgrade.

> IMO we should discuss 2 after 1, and not before.

1 is clear, we all agree on it, there was even a large discution with
upstream, and the agreed upon standard (not just for debian, but for
everyone) is to have onnly one stublibs directory. This is explained in
the README.Debian file some and more in detail in the
ocaml_packaging_policy document.

>   * Is /var/lib/ocaml/ld.conf a conffile?

No, it is not, (but /etc/ocaml/ld.conf is).

It is a generated file, and don't belong to anyone, i think.

>   * Which package owns it?

Same as above.

>   * How is it created?

all ld.conf are created, if they don't exist already, by a ocaml-ldconf
run in the ocaml-base postinst. /usr/lib/ocaml/ld.conf is overwritten if
it exist.

/usr/lib/ocaml/ld.conf is read-only, save for modification by
ocaml-ldconf, in order to stop third party install scripts to write to
it directly.

>   * How is it removed?

It is not.

>   * and other questions related to its modification by other packages;
>     currently postinst and postrm (and not prerm as stated in
>     ocaml_packaging_policy) scripts are used, but this may not
>     be the best option.

In the future, it will be removed from package use, only users or
special package who which to install in a non-standard why.

> Let me try.  As users must have no interaction with this file,
> /var/lib/ocaml/ld.conf must not be a conffile,  It is obviously
> created and removed by the package shipping ocaml-ldconf, i.e.
> ocaml-base.  It must not be part of this package, otherwise it
> is overwritten when upgrading ocaml-base.  So it must be created
> and removed by maintainer scripts.

Yes, this is done in the last (not yet released) version of ocaml-base.

> As ocaml-ldconf creates this file if it does not already exist, its
> presence is not needed by other packages, and calling ocaml-ldconf
> in ocaml-base.postinst looks like a good idea.  It does not hurt if
> another OCaml package is configured first.

:)))

> It seems natural to remove it during 'purge', so only postrm can be
> used for this purpose.

Mmm, yes, how do i do this ?

> Now consider how other packages should call ocaml-ldconf.  When
> installing packages, 'ocaml-ldconf -a' must be called from postinst
> to ensure that ocaml-ldconf do exist.  Similarly 'ocaml-ldconf -r'
> must be called from prerm.
> Mote: if we choose to remove this file when removing ocaml-base,
>       then 'ocaml-ldconf -r' may also be called from postrm.

Right now, it is called from postrm.

But, as the file is to be going away, ...

Notice that all libraries installing stublibs must depend on ocaml-base.

> The fixed script must of course be used to gracefully handle
> upgrades.

:)))

> [...]
> >     => it is empty, then we use postinst-ocamlld-empty, which simply
> >     calls ocaml-ldconf -p<package_name> -R, and will remove all entries
> >     in /var/lib/ocaml/ld.conf corresponding to the package
> >     <package_name>.
> 
> In fact 'ocaml-ldconf -R' could be called in any circumstance,
> 'ocaml-ldconf -r path' is only useful in interactive mode if you
> want to manually change /var/lib/ocaml/ld.conf.  You could also
> state that there is no need for a new -R flag and an empty string
> after -r does the same job.

Yes, i thought about that.

But right now, the behavior of dh_ocamlld is to not write anything to
the postinst/rm if the dirlist is empty.

Also, the plan is to cleanup /var/lib/ocaml/ld.conf in the library
postinst if the dirlist is empty.

> In this mail I only propose a long term solution.  If you agree with
> it, we would then focus on the transition phase.

No, we must discuss this more, i think, since the longterm solution is
to get ride of dh_ocamlld calls in most libraries, keeping the stuff
around for exceptional cases.

The transitional solution is needed to clean up the problem caused with
problematic upgrades.

(But then, it is only cosmetic to have bad entries in
/var/lib/ocaml/ld.conf, so another solution would be to just not cleanup
the mess.

Friendly,

Sven Luther



Reply to: