Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a debian package that installs a file to /usr/local/java/jre/lib/ext, where /usr/local/java is a symlink to where the jvm is actually installed, in this case /usr/lib/jvm/java-6-sun.

The new version of this package installs the jar elsewhere. The problem is that installing the new version causes dpkg to try and tidy up after itself, ending up deleting the /usr/local/java symlink.

This is a deeply undesirable state to be in, even temporarily.

I haven't been able to find the flag for dpkg that will persuade it to leave the symlink in place, and it does not appear to be possible to set the immutable bit on symlinks.

Here are the changes to the debian packaging config:

diff --git a/debian/dirs b/debian/dirs
--- a/debian/dirs
+++ b/debian/dirs
@@ -1 +1 @@
-usr/local/java/jre/lib/ext
+usr/share/java
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -30,7 +30,7 @@ install: build

        # Add here commands to install the package into debian/tmp.
        # $(MAKE) pure_install
-       cp thejar.jar $(TMP)/usr/local/java/jre/lib/ext
+       cp thejar.jar $(TMP)/usr/share/java

 # Build architecture-independent files here.
 binary-indep: build install

I imagine that leaving usr/local/java/jre/lib/ext in dirs would have the desired effect, but this is just kicking the problem down the road - I'd rather that this package not be responsible for maintaining the symlink.

So: what are my options?

share|improve this question

1 Answer 1

Symlinks are just files which the package installs, and so the normal behaviour applies. These are the options I can think of:

  • Mark the symlink as a config file. I don't know whether this is supported, but if it is, the symlink should only be removed if the package is purged.
  • Don't install the symlink as a file, but rather create it in the postinst script.
  • Just create the symlink manually and not as part of the package at all.

Note that whatever the symlink points to is going to be removed when the old version is uninstalled, so I don't see how this make it any better.

share|improve this answer
    
That's the thing though - the symlink was created manually. –  ryanm Aug 14 '12 at 7:39
    
@ryanm Then I don't understand what this has to do with dpkg. –  mgorven Aug 14 '12 at 16:56
    
Because dpkg removes the symlink. Here's the output from installing the new version: Unpacking replacement thepackage ... dpkg: warning: unable to delete old directory '/usr/local/java/jre/lib/ext': Directory not empty dpkg: warning: unable to delete old directory '/usr/local/java/jre/lib': Directory not empty dpkg: warning: unable to delete old directory '/usr/local/java/jre': Directory not empty Setting up thepackage (theversion) ... The advance of deletion attempts towards the symlink is fairly ominous, no? –  ryanm Aug 15 '12 at 14:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.