On 11-10-12 21:11, Paul Gevers wrote: > On 10-10-12 21:41, Julien Cristau wrote: >> Moving things away from /usr/share/cacti/site/plugins manually means any >> update to the package won't be effective. Is there really no better way >> of handling this? > > And one more thing related to the unblock request, just in case it was > not clear already. In the current 0.8.8a-3 package, there is already the > important softlink present, but it fails to work, as the reverse > softlinks are not there and I can not create them. That is why I think > it is better to NOT provide the link, but document the situation. So > this unblock request is really to prevent failures. But do you suggest > to not ship my proposed documentation and let sys-admins install in > /usr/share/cacti/site/plugins? I still believe this is the best solution (as no plugins are shipped in cacti). And I worry that if we leave the package as-is (i.e. cacti in testing already provides a sym-link to /usr/local/...) cacti will get quite some bugs after the release about failing plugins. Do you rather want me to leave out the document describing the suggestion to link to /usr/local/...? That is easy of course. If you are uncomfortable with my proposed change here and can not provide me with an alternative, just a NACK for this unblock is also a good answer, but then I can get this request of my mind. Paul BTW, if I would introduce jsquery/jstree into cacti to fix RC bug 679980 [1] which is about a license issue, would that be considered to invasive? That is the upstream solution (still not implemented yet) to fix the issue. [1] http://bugs.debian.org/679980
Attachment:
signature.asc
Description: OpenPGP digital signature