James Carlson wrote:
> Liane Praza writes:
>
>> I don't inherently cringe. (Others might, but they can speak for
>> themselves.) It's the fact that sqlite3 has an entirely different
>> library API, plus the extensive retesting that would be required that's
>> kept us from prioritizing the w
Nicolas Williams writes:
> On Mon, Dec 01, 2008 at 01:57:58PM -0500, James Carlson wrote:
> > Liane Praza writes:
> > > (SMF's not the only consumer of sqlite2 in ON though, I thought.
> > > Removing SMF's use wouldn't change the other consumers' needs.)
> >
> > The only other one that does the l
Liane Praza writes:
> I don't inherently cringe. (Others might, but they can speak for
> themselves.) It's the fact that sqlite3 has an entirely different
> library API, plus the extensive retesting that would be required that's
> kept us from prioritizing the work since there would be no
> a
On Mon, Dec 01, 2008 at 01:57:58PM -0500, James Carlson wrote:
> Liane Praza writes:
> > (SMF's not the only consumer of sqlite2 in ON though, I thought.
> > Removing SMF's use wouldn't change the other consumers' needs.)
>
> The only other one that does the libsqlite.o reach-around is idmapd,
>
On Mon, Dec 01, 2008 at 09:45:39AM -0800, Liane Praza wrote:
> >Binary size for configd is not likely to be a problem. Using SQLite3
> >would be a very good thing indeed. I figure the SMF team will cringe at
> >the idea of linking with a shared SQLite3; we'll see!
>
> I don't inherently cringe.
Nicolas Williams wrote:
> On Thu, Nov 27, 2008 at 11:22:45AM +0100, "C. Bergstr?m" wrote:
>> So basically what I'm reading in this is when I refactor the build
>> system I may as well evaluate updating to SQLite3. One of the first
>> comments seemed to imply that with SQLite3 there would be an i
On Thu, Nov 27, 2008 at 11:22:45AM +0100, "C. Bergstr?m" wrote:
> So basically what I'm reading in this is when I refactor the build
> system I may as well evaluate updating to SQLite3. One of the first
> comments seemed to imply that with SQLite3 there would be an increase in
> binary size or
Nicolas Williams wrote:
> On Wed, Nov 26, 2008 at 02:59:57PM -0500, James Carlson wrote:
>
>> We had this discussion back with PSARC 2002/117 and the elimination of
>> static libraries from Solaris.
>>
>> I don't believe we should bring them back. Dynamic libraries
>> (including libc itself) ar
On Wed, Nov 26, 2008 at 02:59:57PM -0500, James Carlson wrote:
> We had this discussion back with PSARC 2002/117 and the elimination of
> static libraries from Solaris.
>
> I don't believe we should bring them back. Dynamic libraries
> (including libc itself) are a part of the system, no more or
Nicolas Williams wrote:
> On Wed, Nov 26, 2008 at 07:45:40PM +0100, "C. Bergstr?m" wrote:
>
>> When it comes to building against a multilib based system there's other
>> more elegant ways to depend on specific versions than
>>
>> LIBSQLITE = $(ROOT)/usr/lib/libsqlite.o
>>
>> To really explain w
>
> I'm guessing you'll care about console-login and network-service. I
> can't be sure we're resilient to an absent restarter service, but it's
> at least possible.
>
>> 2) Where does common.db/global.db go after after the build or
>> where/how does the initial database get built/populated?
>
Stephen Hahn wrote:
> * "C. Bergstr?m" [2008-11-26 11:55]:
>
> (These are really questions for smf-discuss at opensolaris.org. I'm not
> closely working on smf(5) at the moment.)
>
>
>> 2) Building svc/* is a pita in a few ways..
>>a. It pulls in objects from other places so to avoid s
Nicolas Williams writes:
> On Wed, Nov 26, 2008 at 02:59:57PM -0500, James Carlson wrote:
> > We had this discussion back with PSARC 2002/117 and the elimination of
> > static libraries from Solaris.
> >
> > I don't believe we should bring them back. Dynamic libraries
> > (including libc itself)
Nicolas Williams writes:
> On Wed, Nov 26, 2008 at 07:45:40PM +0100, "C. Bergstr?m" wrote:
> > When it comes to building against a multilib based system there's other
> > more elegant ways to depend on specific versions than
> >
> > LIBSQLITE = $(ROOT)/usr/lib/libsqlite.o
> >
> > To really expla
On Wed, Nov 26, 2008 at 02:59:57PM -0500, James Carlson wrote:
> Nicolas Williams writes:
> > On Wed, Nov 26, 2008 at 07:45:40PM +0100, "C. Bergstr?m" wrote:
> > > When it comes to building against a multilib based system there's other
> > > more elegant ways to depend on specific versions than
>
On Wed, Nov 26, 2008 at 08:39:57PM +0100, "C. Bergstr?m" wrote:
> Nicolas Williams wrote:
> >On Wed, Nov 26, 2008 at 07:45:40PM +0100, "C. Bergstr?m" wrote:
> >
> >>When it comes to building against a multilib based system there's other
> >>more elegant ways to depend on specific versions than
>
On Wed, Nov 26, 2008 at 07:45:40PM +0100, "C. Bergstr?m" wrote:
> When it comes to building against a multilib based system there's other
> more elegant ways to depend on specific versions than
>
> LIBSQLITE = $(ROOT)/usr/lib/libsqlite.o
>
> To really explain why this should be avoided is an ent
C. Bergstr?m wrote:
>
>>
>> I'm guessing you'll care about console-login and network-service. I
>> can't be sure we're resilient to an absent restarter service, but it's
>> at least possible.
>>
>>> 2) Where does common.db/global.db go after after the build or
>>> where/how does the initial da
C. Bergstr?m wrote:
> Stephen Hahn wrote:
>> * "C. Bergstr?m" [2008-11-26 11:55]:
>>
>> (These are really questions for smf-discuss at opensolaris.org. I'm not
>> closely working on smf(5) at the moment.)
>>
>>
>>> 2) Building svc/* is a pita in a few ways..
>>>a. It pulls in objects f
19 matches
Mail list logo
