#4054 kyotocabinet15-1.2.70

open
nobody
5
2011-11-29
2011-11-17
Steve Huff
No

This is Kyoto Cabinet, the successor to Tokyo Cabinet. It's a database
engine. It's not a drop-in replacement for Tokyo Cabinet; the two packages
can coexist without a problem. However, the developers recommend using
Kyoto Cabinet whenever possible.

It has no OS version restrictions of which I am aware; it builds fine as UID
nobody in maintainer mode on 10.6 x86_64.

It should go in the "libs" section, like tokyocabinet and tokyocabinet9.

I note that the existing tokyocabinet and tokyocabinet9 packages have
BuildDependsOnly set to True, without a note in DescPackaging. It's not
clear to me why this was set this way, but I figure it's probably for a good
reason, so I did the same in my kyotocabinet15 package.

-steve

Discussion

  • Steve Huff
    Steve Huff
    2011-11-17

    .info for kyotocabinet15-1.2.70-1

     
    Attachments
  • Steve Huff
    Steve Huff
    2011-11-17

    patchfile for kyotocabinet15-1.2.70

     
    Attachments
  • Steve Huff
    Steve Huff
    2011-11-17

    dpkg -L kyotocabinet15 kyotocabinet15-shlibs kyotocabinet15-bin

     
  • The package uses g++ but there's no GCC field.

    Also, the api docs are included twice in the base package. The first time under "%p/share/doc/kyotocabinet/doc/api", and the second time under "%p/share/doc/kyotocabinet15/api". This is most likely due to the "doc/" entry in the DocFiles field. If documentation is already being installed by 'make install', there's usually no need to further include it in DocFiles.

     
    • milestone: 373615 --> Awaiting_Update_from_Submitter
     
  • To further clarify, in this case DocFiles for the main package is probably then best served with just:

    DocFiles: README FOSSEXCEPTION LINKEXCEPTION ChangeLog

     
  • What is the status of this item?

     
  • Steve Huff
    Steve Huff
    2012-11-18

    sigh, now i'm seeing a compile error on 10.7 (i've seen it reported elsewhere); i suppose i should report this upstream.

     
  • kcthread patch for clang

     
    Attachments
  • Seeing the failure here as well. Must have been something that changed between xcode 4.1 and 4.5. I've attached a possible patch that I found online. Does it fix the failure?