[5525] in Moira
Re: Two patches
daemon@ATHENA.MIT.EDU (Garry P Zacheiss)
Mon Jan 4 17:10:33 2010
From: Garry P Zacheiss <zacheiss@MIT.EDU>
To: Evan Broder <broder@MIT.EDU>
CC: "moiradev@mit.edu" <moiradev@MIT.EDU>
Date: Mon, 4 Jan 2010 17:06:49 -0500
Message-ID: <37E634B4-81E8-4512-BCB0-5990BE03F4B4@mit.edu>
In-Reply-To: <178868c41001041215h4c2a6d89k7ec8fb1968d04636@mail.gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Ok, sysconfdir patch checked in.
On Jan 4, 2010, at 3:15 PM, Evan Broder broder@MIT.EDU wrote:
> On Mon, Jan 4, 2010 at 12:03 PM, Garry P Zacheiss <zacheiss@mit.edu> wrote:
>> Comments in-line below.
>>
>> On Jan 2, 2010, at 6:33 PM, Evan Broder wrote:
>>
>>> Hi -
>>> I've attached two patches I put together as part of my work on
>>> MacAthena, and one from Debathena
>>>
>>> First, ./configure sets a sysconfdir variable, intended for
>>> system-wide configuration files (i.e. the configurable version of
>>> /etc). respect-sysconfdir.diff causes the update_server to respect
>>> sysconfdir when installing and looking for moira.conf.
>>>
>
> Sure, that works for me - I have no particular attachment to
> /etc/athena/moira.conf vs /etc/moira.conf. From Debathena's
> standpoint, I can be sure to add code to handle that transition, so
> there's no trouble there. New patch attached.
>
>>
>> The Athena 9 build system set sysconfdir to /etc/athena, so this patch ends up setting CONFIG_FILE to /etc/athena/athena/moira.conf in that case. I think it would be more correct for CONFIG_FILE to get set to $(DESTDIR)$(sysconfdir)/moira.conf rather than sticking the random "athena" in there; I don't think the file ending up in /etc is wrong.
>>
>>> Second, OS X has a bizarro version of com_err. For whatever reason,
>>> initialize_FOO_error_table() is a NOOP; unless you call
>>> add_error_table(&et_FOO_error_table) instead, com_err doesn't have
>>> access to the error tables and you get numeric error messages. Except
>>> for libkrb5, where you need to build with -framework Kerberos to get
>>> access to the error tables (but don't need to call add_error_table).
>>> Like I said, bizarro.
>>>
>>
>> Looks good, committed.
>>
>>> fix-os-x-comerr.diff updates both the build flags and
>>> initialize_FOO_error_table calls to do the correct thing. Both patches
>>> will only have any effect if Moira is being built on OS X. (The patch
>>> to configure.in is based on r23277 I committed to Debathena a while
>>> back).
>>>
>>> Finally, now Moira can be built as a shared library, but it's not
>>> possible to build additional out-of-tree clients against it, because
>>> the headers aren't currently installed. I'm particularly interested in
>>> seeing the headers installed for my Python bindings to libmoira[1],
>>> which Debathena is hoping to use in a series of more user-friendly
>>> graphical Moira clients in the near future. install-headers.diff
>>> installs <moira/moira.h>, <moira/mr_et.h>, <moira/krb_et.h>, and
>>> <moira/ureg_err.h>. I put them under the moira/ subdirectory to avoid
>>> any potential conflicts with krb_et.h, but if you'd prefer to see them
>>> go directly into $(includedir), that's fine with me as well.
>>>
>>
>> I dither about this one, not because of the content (putting headers under a moira subdir is fine), but because I'll admit I currently like the fact that there aren't really any clients outside of the canonical source tree. In the specific case you're thinking about, I would be interested in taking well-thought-out python bindings into the tree (to compliment the JNI code that's already there) if you'd be interested in seeing them incorporated; this is likewise true for any additional clients you're considering writing. You should note that ISDA has been working on a new webmoira, so if there's functionality you'd like, I'd also strongly consider seeing if they would include it there rather than writing something standalone.
>
> I understand the hesitation. Honestly, though, I don't think the lack
> of Moira client proliferation is connected to the impossibility of
> building one. It's already possible to do whatever you need by
> shelling out to the existing clients, especially when you count
> mrtest/qy in your list of clients. And I really would expect that
> anybody with the clue to write their own Moira client at all has the
> clue to go find the headers.
>
Sure, it's hard to make it impossible, just a question of where we set the bar.
I suspect I'll come down on the side of committing the patch, but I'd like a little time to mull it over first.
> Either way, though, I'd definitely be interested in seeing my Python
> bindings incorporated into Moira itself. In fact, there are a few
> things that I'll be able to do much more cleanly as a part of the
> Moira tree (exposing error codes easily comes to mind). I'll see if I
> can get you a patchset some time this week.
>
That would be great.
> One thought I had was that, if I was doing Python bindings for
> libmoira itself, it would also be really nice if we also had Python
> bindings for libmrclient, so that apps using the Python modules
> wouldn't need to duplicate code, but Python gets snippy if you try to
> build extensions against statically linked libraries. Would you be
> amenable to a patch to build libmrclient as a shared library as well
> as libmoira?
>
Nope, that would be fine.
> - Evan
> <respect-sysconfdir.diff>
Garry
