Re: [mdb-dev] [mdbtools-dev] Many patches, is that project dead? Fork?

[Tim R. <ti...@re...>]

On 17 June 2010 14:52, Brian Bruns <br...@br...> wrote:
> 2010/6/16 Nirgal Vourgère <con...@ni...>:
>> patches/015-allsyms
>>        Add the necessary sql and odbc library dependencies.
>
> Applied.

I think the way that libmdbodbc is statically including libmdb should
be changed - that patch just fixed the immediate problem.

That will automatically mean an API break, iirc.

>> patches/038-removals
>>        Factorisation of code for macro/module/query/report
>> patches/041-eggiconlist
>>        Icons, gtk
>> patches/045-aboutdialog
>>        Use of gtk_show_about_dialog rather than custom widget
>
> Didn't have time to properly evaluate these yet, but maybe you can
> give me the run down?  It appears to commonize the handling of the
> icon lists?  Also, appears to remove gnome calls in favor of gtk
> equivalents.

I can't actually find who wrote these, so it's tempting to rewrite
them. Unless they came from CVS, but that seems unlikely?

The last one seems separate - at some point a standard gtk "about"
dialog was introduced, so this is just trying to make things
consistent.

The first two replace GnomeIconList with EggIconList. At some point
the former became deprecated - but it's a bit pointless without also
removing the other libgnomeui dependencies.  This might become more
pressing in the next year or two, because libgnomeui will be going
away altogether.

>> patches/055-iconv-config
>>        Do not #include <config.h> in public headers.
>
> Didn't apply yet, but will.

Eh, there seems to be a typo in the comment in the makefile. (Rene's
the openoffice.org maintainer in Debian.)

>> patches/070-unixodbc-api
>>        Fix 64-bit issues with the ODBC support.
>
> Need to look at.

http://bugs.debian.org/360436 was the Debian bug.  Apparently unixodbc
breaks API occasionally.

>> patches/094-add-man-pages
>>        Add man pages for several binaries.
>> patches/096-use-system-txt2man
>>        Use system txt2man.
>
> What if txt2man is not there? Might go ahead and apply, but need to
> test what happens if there is no txt2man is available (used to be much
> more common occurrence than it is now), I'm fine with not installing
> man pages if not found, but I want to make sure the behavior is
> correct.

Hmm, I'd ship the generated man pages in the release tarball, and just
make developers install txt2man.

-- 
Tim Retout <ti...@re...>