plug-ins in /usr/local/share/cacti need symlinks to /usr/share [was] plug-ins in /usr/local/share don't find include files in ../include

2012-07-28 Thread Paul Gevers
Ping [additional info as well] [and please CC 681...@bugs.debian.org].

On 14-07-12 18:04, Paul Gevers wrote:
 This morning I filed bug 681558 [1] against my co-maintained package
 cacti. When I was filing it, I was under the impression that the
 solution would be simple, creating a soft-link from
 /usr/local/share/cacti/include - /usr/share/cacti/site/include. Before
 I starting implementing it I decided to have a look at the policy about
 such things, but unfortunately, unless I am much mistaken, this is not
 allowed (section 9.1.2) [2].
 
 So my question is how to deal with the following problem. Since cacti
 0.8.8, the package supports plug-in architecture. This means that the
 system administrator can add plug-ins to his installation to enhance the
 functionality of cacti. As cacti is installed in /usr/share/cacti, and
 the administrator is not supposed to add site specific things there, I
 decided to let the admin put his plug-ins in
 /usr/local/share/cacti/plugins and soft-link
 /usr/share/cacti/site/plugins to that location. The bug I filed [1], is
 about how this fails as some (or all, I have not tested yet), assume
 that they are installed in a sub-directory of the main cacti
 installation (including things like ../include/auth.php). I already
 requested [3] upstream to allow for a system where the plugin directory
 can be configured and I assume these kind of problems will, if accepted,
 go away automatically. But until then, should I just consider plug-ins
 that do this broken, and write in README.Debian that admins could create
 a soft-link themselves (after I confirm that this really solves the
 issue), or are there other possibilities that I have not thought of so far?
 
 Are there other packages that have similar demands or problems?
 
 Kind regards,
 Paul
 
 [1] http://bugs.debian.org/681558
 [2] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
 [3] http://bugs.cacti.net/view.php?id=2227

Some additional info: The problem is that several plug-ins are using php
chdir('../../') to move down the tree before doing includes, but the php
implementation of chdir resolves symlinks [4], so in the end the plug-in
can not find the include and lib directory. So the solution is in
rewriting the plug-ins, but that is out of reach for me.

[4] last comment of http://php.net/manual/en/function.chdir.php

Paul



signature.asc
Description: OpenPGP digital signature


plug-ins in /usr/local/share don't find include files in ../include

2012-07-14 Thread Paul Gevers
Hi all,

This morning I filed bug 681558 [1] against my co-maintained package
cacti. When I was filing it, I was under the impression that the
solution would be simple, creating a soft-link from
/usr/local/share/cacti/include - /usr/share/cacti/site/include. Before
I starting implementing it I decided to have a look at the policy about
such things, but unfortunately, unless I am much mistaken, this is not
allowed (section 9.1.2) [2].

So my question is how to deal with the following problem. Since cacti
0.8.8, the package supports plug-in architecture. This means that the
system administrator can add plug-ins to his installation to enhance the
functionality of cacti. As cacti is installed in /usr/share/cacti, and
the administrator is not supposed to add site specific things there, I
decided to let the admin put his plug-ins in
/usr/local/share/cacti/plugins and soft-link
/usr/share/cacti/site/plugins to that location. The bug I filed [1], is
about how this fails as some (or all, I have not tested yet), assume
that they are installed in a sub-directory of the main cacti
installation (including things like ../include/auth.php). I already
requested [3] upstream to allow for a system where the plugin directory
can be configured and I assume these kind of problems will, if accepted,
go away automatically. But until then, should I just consider plug-ins
that do this broken, and write in README.Debian that admins could create
a soft-link themselves (after I confirm that this really solves the
issue), or are there other possibilities that I have not thought of so far?

Are there other packages that have similar demands or problems?

Kind regards,
Paul

[1] http://bugs.debian.org/681558
[2] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
[3] http://bugs.cacti.net/view.php?id=2227



signature.asc
Description: OpenPGP digital signature