On 2013-09-18 23:14:35 +0200, Kurt Roeckx wrote:
> I mean, if you install any library via a Debian package,
Note that the library was *not* installed via a Debian package.
In my case it was installed under my home directory.
> it should result in ldconfig being run.
But ldconfig as run via Debian package installation must not touch
non-system directories, in particular libraries under the user's
home directory. So, such directories should be completely safe.
Even for system directories, the user may want to test various
versions of the library in /usr/local/lib just after installing
them, so that it won't normally be affected by installation of
Debian packages if the tests are done immediately. Anyway the
user should be aware that specific things may occur with system
directories, which are partly controlled by the system and should
normally not be used for experimentation.
Also the fact that the system does special things with system
directories is not a valid reason for doing such things via
"make install".
> But I would also find it normal that a "make install" doesn't run
> ldconfig.
>
> I'm not sure what I expect the result of "make install" to be.
> Should it update the symbolic link? Or should it just copy the
> file?
It should do the minimal steps
1. to make the software (application, library...) directly usable
(the installed version, not a different one);
2. without touching other software, except when absolutely necessary
to fulfill (1).
In practice, (2) means that other versions (previously installed) of
the installed software (and other software depending on them) may no
longer work.
If for some reason, it can be detected that (1) cannot be fulfilled,
then the installation process should end with an error: a clear error
message and a non-zero exit status. This will allow the user to detect
the problem and decide what to do.
> I'm actually expecting it to just install the file and not update
> any symbolic link and that ldconfig should do that.
I think that the symbolic link should be updated to the installed
version, because the ultimate goal of library installation is to
be able to use it.
Also note that the current description of Libtool's versioning system
(Libtool manual Sections 7.2 and 7.3) clashes with ldconfig behavior
(and more generally with library installation, but ldconfig makes this
worse). As I've said in
https://sympa.inria.fr/sympa/arc/mpfr/2013-09/msg00019.html
--------
# Libtool -version-info CURRENT[:REVISION[:AGE]] for libmpfr.la
#
# 1. No interfaces changed, only implementations (good):
# ==> Increment REVISION.
# 2. Interfaces added, none removed (good):
# ==> Increment CURRENT, increment AGE, set REVISION to 0.
# 3. Interfaces removed or changed (BAD, breaks upward compatibility):
# ==> Increment CURRENT, set AGE and REVISION to 0.
Now assume that there are two MPFR versions x.y and x.y' with entirely
(backward *and* forward) compatible interfaces, for instance because
only some algorithms have changed. Then these two different versions
would have the same CURRENT and same AGE values. For patch releases,
one could make sure to increase REVISION by skipping values already
used by the other version, but if such releases get installed, this
could mean that the highest version would not necessarily be used.
For instance, one could have the successive releases:
version -version-info
5.2.0 17:0:6
5.3.0 17:1:6
5.2.1 17:2:6
When 5.2.1 is released (fixing bugs only present in 5.2.0), if it is
installed while 5.3.0 is also already installed, then 5.2.1 will be
chosen instead of 5.3.0 by the linker.
--------
With ldconfig, this makes such things worse, because even if 5.3.0
is (re)installed after 5.2.1, ldconfig will revert the version to
5.2.1 (due to higher REVISION).
So, I've said then:
IMHO, to avoid such problems, I think that we should always increment
CURRENT for new MPFR minor or major versions; revisions would just be
incremented for patch releases.
i.e. increment CURRRENT even if the most recent interface remains the
same.
If this is the good way to do, then Libtool manual Sections 7.2 and
7.3 should be corrected.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
