Opened 6 years ago

Closed 6 years ago

#11925 closed Patch - Bug Fix (Won't Fix)

Symlinks to external files no longer served by mythbackend

Reported by: pmhahn@… Owned by: dblain
Priority: minor Milestone: 0.27.1
Component: MythTV - UPnP Version: 0.27-fixes
Severity: medium Keywords: symlink Debian
Cc: Ticket locked: no


Packaging MythTV for Debian requires to re-use the already packaged JavaScript? libraries jquery/prototype/scriptaculous as provided by Debian in /usr/share/javascript/. With Apache they're made available via http://.../javascript/..., but since MythTV has it's own http server implementation at TCP port 6544, I tried to put links into /usr/share/mythtv/html/js/ to /usr/share/javascript/, which were not served by MythTV.

The original implementation (28c30ecf 2011-03-09) used QDir.makeAbsolute() to resolve relative path into absolute paths, which does not resolve symbolic links. Because of that the original code contains an explicit call to isSymlink() and symLinkTarget().

Later on (381c2ebf 2012-07-13) the code was changed to use canonicalPath() and canonicalFilePath() to resolve "../"s and symlinks in the path, which

  1. renders the explicit code to handle symlinks obsolete,
  2. breaks the case were the symlink deliberately points outside MytvTVs http server directory.

The attached path implements a compromise, where only the directory is required to to be inside MythTVs web directory, but links can point outside it.

Attachments (1)

allow_symlink.patch (1.0 KB) - added by pmhahn@… 6 years ago.
Allow symlinks to external files; needs to be checked on Windows

Download all attachments as: .zip

Change History (4)

Changed 6 years ago by pmhahn@…

Attachment: allow_symlink.patch added

Allow symlinks to external files; needs to be checked on Windows

comment:1 Changed 6 years ago by sphery

Is the couple hundred kilobytes of HDD space savings really worth the added complexity of using the system versions of (parts of) a couple of minor JavaScript? libraries? Using system libraries requires that packagers test and verify that the (presumably ever-being-updated-beyond-MythTV's) version of the system libraries is compatible with the MythTV code and marking compatible/not-compatible versions in the package management system. Note that this is a problem not only for packagers, but also for users who must figure out why upgrades are being blocked and/or must figure out a way to work around the package management system when they need to upgrade the system libraries to a version that's not compatible with the MythTV code.

It seems that installing a separate copy of the JavaScript? library code used by MythTV--a copy that's guaranteed to be compatible with the MythTV code (because it was used to develop that code) and that can be upgraded only when MythTV is ready for the upgrade--is a much safer and better approach. I recommend just installing the files MythTV installs.

comment:2 Changed 6 years ago by pmhahn@…

It's less about the size, but about maintenance: From MythTV point-of-view it might be okay to include all dependent software packages to ease the direct installation for end-users, but for Debian, which contains thousands of packages, it would be a night-mare if every package contains its own copy of a favorite library: If ever a security patch needs to be applied, the Debian security team would have to patch all packages and apply the - if they;re lucky - same patch multiple times - in the unlucky case they would need to apply slightly different patches to slightly different versions. Therefore it's Debians rule to package libraries once and for every package to use that one packages version. Here are some numbers, to give you an idea, on how many packages already use this approach in Debian: $ apt-cache rdepends libjs-jquery | wc -l 455 $ apt-cache rdepends libjs-scriptaculous | wc -l 26 $ apt-cache rdepends libjs-prototype | wc -l 37 And if one would follow your scheme, you also wound need to include Qt, Glibc, X11, a Kernel and so in with MythTV. as "they're the version testes by the MythTV developers", so your should probably do your own binary-only releases shipped on MythTV certified hardware — just kidding, but I hope you get the idea ;-) On the main Debian-ML there's just another discussion on also packaging ffmeg, as Debian currently only has libav. Our security maintenance team is strongly against including a second version, as they're already overloaded with patching the security holes in libav; and I can really understand there POV that they don't want to do that multiple times also for ffmpeg, VLCs version of ffmpeg, mplayers version of ffmpeg, MythTVs version of ffmpeg, ... So for Debian that patch is needed; we can carry it on as a Debian-only patch, but others might benefit from that too, so that's why I created the ticket.

comment:3 Changed 6 years ago by stuartm

Resolution: Won't Fix
Status: newclosed

MythTV includes copies of some libs because it depends on _specific_ versions of those libs. Linking other libs is just liable to create bugs as has repeatedly happened with debian packages - to the extent that a lot of application developers are pissed off with Debian packagers thinking they know better than the people who actually wrote the application. In some cases inept packagers have created real security problems instead of fixing theoretical ones.

If Debian packagers want to alter the code they supply to their users, then they can stop calling it MythTV because it's NOT.

Note: See TracTickets for help on using tickets.