First of all, let's all agree that this is not a clear cut case.
We definitely have a bug here, aside from this discussion, and this is
that we don't ship the agi-bin directory even though we referenced this.
Sadly, Andew Pollock didn't report this as a bug when he found it.
Tim Retout wrote:
With web servers such as Apache, it is generally possible for the
administrator to configure other cgi-bin directories at different
locations. Administrators do not have to put their custom CGI scripts
in /usr/lib/cgi-bin.
Asterisk can have only one agi-bin directory, so I do not think this is
comparable. (Hardcoding the full path in extensions.conf is not really
the same.)
This is the whole point of this discussion.
We're trying to find a single path that will fulfill different needs
(shipping AGIs from packages AND provide a way to install site-local AGIs).
It is an upstream bug that has hit us many times before -- we had to do
a symlink workaround recently for the location of the sounds.
This also has the benefit of retaining some compatibility with
upstream's location.
Upstream is incompatible with FHS. A symlink there might cause
confusion.
I have to agree with Tzafrir here on both points:
a) upstream is known for not caring less about the FHS
b) afaict, we are going to need symlinks for each and every package or
provide scripts that do that. Not really a solution.
I am mostly thinking about administrators writing custom AGI scripts,
and wanting to have them included in the agi-bin directory. They could
have different scripts on each host.
If they put their custom scripts into /usr/share/asterisk/agi-bin, then
the scripts may be overwritten by system upgrades; there is no guarantee
that a Debian package might not accidentally choose the same name as one
of the local scripts. See footnote [27] of FHS 2.3:
http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1450
Agreed so far.
Requiring administrators to add their own host-specific scripts
under /usr also goes against the FHS (and therefore Debian Policy); the
intention of the /usr hierarchy is that it is "shareable, read-only
data" that is not host-specific - it could potentially be shared between
different machines:
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
Well, I don't exactly agree to the "host-specific scripts".
If we go down this road, then the whole /usr/local should go away
(think of perl, python etc.)
[Technically, site admins should perhaps be using somewhere under /srv
for host-specific scripts, not /usr/local:
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
...but it looks like it would be unwise for packages to install anything
there themselves.]
Not only we cannot put stuff in /srv (not even subdirectories, unlike
/usr/local) but we cannot even make assumptions that something may
reside there.
I believe symlinks in /var/lib/asterisk/agi-bin can be considered state
information of the system (i.e. the set of currently available AGI
scripts on this host) and fits the FHS criteria:
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
That is a stretch and totally incorrect, sorry.
So, I hope this isn't just making things more complicated for nothing -
it could be interpreted as a violation of a "must" directive in Debian
Policy (section 9.1.1).
That may be a legitimate bug but it's hardly a policy violation.
I presume you agree, since you didn't file it as "serious", even though
you are aware of our procedures.
All in all, I believe that we may have to support multiple directories
(i.e. also supporting /usr/local) and the only way I can see for doing
that is by modifying asterisk's source.
I'll have a look and try to produce a not very crude hack to do that.
I will also try to move this discussion with upstream -- may be we can
agree on a proper solution.
Thanks,
Faidon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
