[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libmspack's debian/



Hi All,

FYI:  None of this is determined yet.  I am simply trying to create a 
prototype that can prove that the idea of a Font Installer wizard will work.

Once that is done, I will ask permission from Hamburg developers if we can 
include it in the OpenOffice.org tree in external (Martin and Sun legal will 
have to approve it first).

Privately Stuart sent me a nice simple list of build instructions so 
integrating this into external will be qute easy.  

So I will be adding an "uncabinet.c" file (based on cabrip.c and cabd_md5.c as 
suggested by Stuart (thank you again!) and an OOo makefile.mk that will be 
built right alongside specific files in the mspack/ subdirectory to create a 
simple command line tool called "uncabinet".  No static library libmspack.a 
will be built or delivered, only an "uncabinet" simple command line tool.

This tool will then be invoked by a Basic "Wizard" macro which will download 
the MS core fonts and "uncabinet" them and install them along with probably a 
set of URW font files and other fonts needed for specific locales (only the 
MS fotn files need the "uncabinet").

So I was not planning a full blown inclusion of libmspack.a or (shared 
versions) and was instead generating a simple "uncabinet" command line tools 
to be utilized solely by the Font installer wizard macro code.

However when the functionality of libmspack increases to include most of the 
features he plans, or  if some other need arrises to deal with other MS 
archive formats, I would then recommed building a whole "component" wrapper 
around libmspack.a so that other OOo components can use its services as they 
see fit (just like we do with the zlib component we build as well).

So for the foreseeable future, Debian need not worry about integrating 
libmspack separately from OOo (although I am sure that would be nice for 
everyone involved), since upstream OOo would do the build with its own 
makefile.mk process to create just an "uncabinet" command line tool.

Again, even if I can get all of this to work, there is no guarantees that 
Hamburg/Sun legal will approve the addition of the code (but since it is pure 
LGPL and quite useful code, I sure hope they will). 

Thanks,

Kevin


 



On Saturday 24 January 2004 11:37, Rene Engelhard wrote:
> Hi,
>
> OOo is going to use libmspack in one of their next versions as it seems
> [1]. So I checked out the CVS (as you told Kevin) to look over it.
>
> Sorry, but the debian/ directory is seriously broken.
>
> It
>
>   a) names the package libmyspack while Debian policy requires splitting
>      the package into libspackSONAME and libmspack-dev. Since there is
>      no shared library here the package should produce libmspack-dev
>      containg the headers and the static library.
>      So or so libmspack is wrong.
>
>   b) nothing is installed into the deb anywhere except usr/share/doc/...
>
>   c) debian/copyright is missing
>
>   d) has oudated DH_COMPAT and Standards-Version:
>
> debian/ is CVS is IMHO a BAD IDEA anyhow, since that quickly gets out of
> sync. The coresponding Debian packager could have debian/ in his CVS
> anyhow or something...
>
> A bug in the configure script is that CFLAGS in the environment isn't
> honoured. That's necessary for Debian policy since we have to build with
> -g during build anyhow and strip later and we should support easy
> switching between -O0 and -O2 in debian/rules via an envvar.
>
> The diff attached here fixes at least the debian/ stuff and cleans some
> stuff out... Markus, if you really want to maintain libmspack you probably
> have to RTFMs more. And depending on whether Kevin wants to integrate it
> into OOo 1.1.1, we need it in Debian unstable relatively soon... [2]
>
> [1] as posted on dev@porting.openoffice.org
> [2] Debian has the viewpoint that is is better to use an own package
>     (in this case libmspack-dev then including all things into the
>     OOo source and build it with it....)
>
> Grüße/Regards,
>
> René



Reply to: