Re: purge_ld_conf.pl [Was: Re: the move to stublib]
On Tue, Sep 10, 2002 at 12:32:07AM +0200, Denis Barbier wrote:
> On Mon, Sep 09, 2002 at 05:14:00PM +0200, Sven LUTHER wrote:
> [...]
> > So, the long term goal is to have all packages install the stublibs into
> > the standard place (and have all hand installed stuff put them into
> > /usr/local/lib/ocaml/<version_number>/stublibs), so there is no more
> > complex ld.conf handling necessary.
> > Ocaml-ldconf will include these two dirs as hardcoded in ocaml-ldconf
> > generating /usr/lib/ocaml/ld.conf (from the /etc and the /var ones, as
> > before).
> >
> > We need to keep the current scheme going though, because it can server
> > other purposes, and to keep backward compatibility with older libs, to
> > give a breathing time for library maintainer before they have to change
> > their packages acordyingly. (as an example, i did change mlgtk so it now
> > complies to the new scheme, but i have keept camlzip still complying to
> > the old scheme).
> >
> > Does this clarify things for you, or should i give more precisions ? In
> > the later case, please tell me what exactly is that needs clarification,
> > so i can respond to those questions.
>
> Thanks for these explanations.
Ok, sorry it was not clear for you, i think we spoke about this in
earlier mails on this list, but then maybe most other people knew it
because of the discution on the upstream caml-list, from where i cross
posted some mails, but maybe not all.
> [...]
> > The only real problem is that the new scheme does not really need this
> > complexity anymore, so we will slowly phase it out, but keep it around
> > in a working phase for exceptional uses and for easing the transition
> > phase on library maintainers.
>
> There are at least 2 alternatives:
> a. a centralized clean-up, performed for instance by ocaml-base postinst
> b. all libraries perform their own clean up.
or :
c. don't do anything about it.
> If you choose (b), then calls to dh_ocamlld must be put in debian/rules
> until sarge is released, and ocaml_packaging_policy must document this
> practice.
> OTOH with (a) there is no transition phase except for ocaml-base.
> IMHO (a) ease maintainers' life.
Well, that was also Stefano's opinion, but i don't really agreed on this at the time.
Now i am having second thoughts about it.
The problem with a is how will you achieve it ?
o As stefano did, parse the /var/lib/ocaml/ld.conf, check all the
directories that are found in it, and have remove the entries with
empty directories.
Well there are two problems with this:
=> The first is only potential since the /var/lib/ocaml/ld.conf is not that
big anyway, it is that we have to list directories to see if they are empty,
which may be a bit heavy for the system, especially if we do this many
times. As said, we could get the package list of /var/lib/ocaml/ld.conf and
then parse the postinst script of these package, and execute the
"ocaml-ldconf -pxxx -a dirlist" we found there after having removed
the packages by hand. This would entail a reading of 1 file per
package, some grepping in it, and a ocaml-ldconf -a run, as opposed to
1 check per directory, so i don't know if we gain much.
Additionally, packages may well have a valid reason for listing empty
dirs, like having a stublibs creating program which will later fill
this dir for example. Stefano's solution will break this, but not the
postinst parsing one. That said, There is no such package right now
anyway.
=> The second problem is that if the cleanup script is only run one
ocaml-base is installed, if later on we upgrade a broken library, We
will have to rerun it. The granularity of ocaml-base installs is not
enough, i think, but then like said, it _is_ a cosmetic change.
So after thinking about all this, i came up with the following scheme :
We have 3 cases :
o libraries which provide a dirlist : dh_ocamlld -pxxx dirlist.
=> these would work as usual, and would not be broken, only if the
dirlist did change between an older, broken, version and the current
one.
o new libraries which did not exist before we fixed dh_ocamlld.
=> no problem, we remove any dh_ocamlld from debian/rules, and there
is no problem.
o libraries which previously had dirlist but not anymore, and have
cruft in /var/lib/ocaml/ld.conf.
=> This is the problematic case, in these case we just keep a call to
dh_ocamlld -pxxx around, but without any dirlist. dh_ocamlld will
notice this (for now) and just add a call to ocaml-ldconf -pxxx -R in
the packages postinst. Later on (post sarge) we change dh_ocamlld
again so that it simply ignores this kind of call, adding maybe a
message saying that dh_ocamlld can be removed from debian/rules or
something such, and that's it.
In this way, we have the benefit of doing it per library, without any
effort involved on the part of the library maintainer (which mostly
are just stefano and me and maybe a few others, i think, well, mostly
stefano anyway if you count the number of libraries packaged).
Sure the maintainer needs to have a call to dh_ocamlld -pxxx in
debian/rules, but he would have to change the debian/rules anyway, to
remove the old dh_ocamlld -pxxx dirlist call. This can be done in two
ways : remove it or call it with an empty dirlist, not sure what the
other library maintainer did choose to do.
(Ideally i was going for a much more complex scheme, where you would add
a dh_ocamlld -pxx -R <version>, where the version was the one in which
the problem was fixed and have dh_ocamlld generate a script of the form
:
if version > $2 then ocaml-ldconf -R fi.
since $2 would contain (in the configure case) the version of the
package we are replacing.
This would have all the benefit of the above, but would run the
ocaml-ldconf -R only if it is really needed. It will be a little more
work for the library maintainer, but then, the dh_ocamlld call could be
around forever or something suhc, since it would not cost much anyway.
It would need a change to dh_ocamlld, a change which would include the
parsing of option (the -R <version> one at least), and maybe a -G for
use with ocaml-base, which is something more heavy, and you told me that
it was too much work or something like that.
So in conclusion :
o either we go for a centralized script, but i would choose the
postinst parsing one, and have it implemented as a --cleanup (or -c)
option to ocaml-ldconf, and have it called from ocaml-base, and maybe
also by hand later on.
o or we go with a per library scheme, where we are sure we don't miss
anything, in either it's more complex form (with version checking) or
not.
Note, we could go with both solutions also, just to be sure.
Friendly,
Sven Luther
Now, i would go with
>
> Denis
Reply to: