Mono /usr/share/doc symlink problem

Bug #344750 reported by Jo Shields
4
Affects Status Importance Assigned to Milestone
mono (Ubuntu)
Fix Released
Medium
Steve Langasek

Bug Description

Binary package hint: mono

In Jaunty, we moved from merging Mono, to syncing it. One side-effect of this, however, is that upgrades from earlier releases suffer from problems with /usr/share/doc/foo entries sources from the mono source package, as packages which were symlinks here in Ubuntu are not correctly transitioned to independent folders in Debian.

Whilst the Mono team discusses long-term solutions, the simplest short-term fix here is to move back to symlinking for Jaunty, and worry about migration paths in a later release Karmic or later)

Revision history for this message
Jo Shields (directhex) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :

That won't repair partially broken upgrades, and while you are at it, you could just as well fix it properly. If a symlink changes to be a real directory on upgrade, you need to remove the symlink in the preinst before upgrade. That isn't hard to do, and will be much more robust.

Changed in mono (Ubuntu):
status: New → Incomplete
Revision history for this message
Jo Shields (directhex) wrote :

Revised debdiff attached, if this is still wrong, then I'm obviously missing something about what you're asking for

Changed in mono:
status: Incomplete → New
Revision history for this message
Martin Pitt (pitti) wrote :

Ugh, nice trick with this .preinst.debhelper hackery to avoid writing debian/<package>.preinst yourself.

Were those symlinks really so widespread to warrant this evil trick, though?

$ find /usr/share/doc -maxdepth 1 -type l -name '*mono*'
/usr/share/doc/mono-jit

If it's just that one, it's much more robust and obvious to just create debian/mono-jit.preinst and rm -f /usr/share/doc/mono-jit in it on upgrade.

Revision history for this message
Jo Shields (directhex) wrote : Re: [Bug 344750] Re: Mono /usr/share/doc symlink problem

mono-jit is the only one whose symlink remains - it's the only one which
is technically policy-compliant, as it Depends on mono-common (=
${binary:Version}).

As for widespread, ALL packages made by the mono source package on older
Ubuntu releases used the symlinking trick, meaning about 30 instances on
this system

Revision history for this message
Martin Pitt (pitti) wrote :

I see, thanks. So this sounds ok for uploading.

Revision history for this message
Steve Langasek (vorlon) wrote :

FWIW, I would prefer to see the symlink removal guarded by a version check, just so we avoid messing with the filesystem in cases where any symlinks there aren't the doing of the packages in question.

And the use of mixed quoting conventions in debian/rules makes me twitch.

But I'm grabbing this for sponsorship to karmic anyway. (I don't think it warrants an SRU to jaunty, FWIW, though if there's going to be a mono SRU for something else we could consider including this change.)

Changed in mono (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
importance: Undecided → Medium
status: New → In Progress
Revision history for this message
Jo Shields (directhex) wrote :

I'll discuss implementation of *a* solution at the Debian level with
Mirco, for inclusion in the 2.4 packages which will eventually land in
Karmic.That way we can use a simple "if Ubuntu AND < 2.4" check. I
don't know what he'll agree to though. The difficulty is in finding a
way to save space through symlinking, but without violating Policy.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mono - 2.0.1-6ubuntu1

---------------
mono (2.0.1-6ubuntu1) karmic; urgency=low

  * debian/rules:
    + Stop symlinking /usr/share/doc entries, to try and bring Ubuntu
      into line with Debian. (LP: #344750)

 -- Jo Shields <email address hidden> Mon, 30 Mar 2009 10:13:16 +0100

Changed in mono (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.