[CalendarServer-dev] [CalendarServer] #317: System install (run's -i option) ambiguities
CalendarServer
trac at macosforge.org
Thu Jan 15 04:56:39 PST 2009
#317: System install (run's -i option) ambiguities
-----------------------------------+----------------------------------------
Reporter: AxelLuttgens@… | Owner: wsanchez@…
Type: Defect | Status: new
Priority: 5: Not set | Milestone:
Component: Calendar Server | Severity: Other
Keywords: |
-----------------------------------+----------------------------------------
I don't know how to classify this one. It may just prove to be strictly
cosmetic, or contrary wise reveal some glitches in the logics of the run
script; if the latter, this ticket could then be related to ticket #316.
A system install seems to know about /System/Library and /Library. Those
directories are typical of Mac OS X. But then, why does such an install
put things into /usr/local/bin as well, instead of /usr/sbin or /usr/share
for example?
The installation location for caldavd.plist is rather surprising:
/System/Library/Frameworks/Python.framework/Versions/2.5/caldavd:
caldavd.plist...
If a system install insists on putting things under /usr/local/bin, why
does the default config (as of config.py) still consider that twistd's
path is /usr/share/caldavd/bin/twistd?
In the same vein, and this seems to be directly related to #316, a PATH is
set to a non existing
/System/Library/Frameworks/Python.framework/Versions/2.5/bin...
As a result, the default layout yielded by run's -i option really appears
as an hybrid install: many similarities with a home install and some
reminiscences of what may be observed on Mac OS X Server.
More generally, the rationale underlying the -i and -I options don't
appear clearly.
Unless some bug (typo) is at work.
Unless I just don't understand those matters...
TIA,
Axel
--
Ticket URL: <http://trac.calendarserver.org/ticket/317>
CalendarServer </>
HTTP/WebDAV/CalDAV Server
More information about the calendarserver-dev
mailing list