Re: Re: debian packaging

>> I am using buildrelease/makedist.py as the Makefile/build.sh.
> 
> This still seems to concern itself only with packing things up (in
> frozen form, no less), 

The frozen form is just three of the three current ways of packaging
things up :-)  There will be a fourth that just makes a tree below
dist.

> rather than running swig and building native code 

packaging/buildmodules.py

> or ensuring that any output has been cleaned up properly.

What specifically are you referring to?

> Thanks, but it is honestly saner to keep the Debian packaging separate

Ok.  I do want to keep your seperate files as small as possible though
especially so they don't duplicate what should be in the BitPim source.

> Plain text, with some formatting conventions.  You can view it at
> http://packages.debian.org/changelogs/pool/main/b/bitpim/bitpim_0.8.08.dfsg.2-3/bitpim.copyright
> but a few lines are Debian-specific.  (OTOH, maintaining a detailed
> list of outliers in your LICENSE file would make it easier to ensure
> that the Debian copyright file is complete and up to date.)

I am definitely not the only copyright holder -  I think you'll
find others have written more code than I have!

The xyaptu.py file is based on code that was under the BSD license
not the Python license.  The recipe pages at the ASPN cookbook
website do not say anything.  However I happen to own the O'Reilly
book that was printed from all that together with editorial notes
and had this recipe in it.  The foreword to the cookbook says they
contacted all the authors and that all the recipes in the book
are consequently under the BSD license.

Is the file allowed to include pointers to licenses (ie URLS) or
do you have to include the whole body as well.  I'd like to get 
to the point where you can lynx -dump the following pages:

  http://bitpim.org/help/licenseandwarranty.htm
  http://bitpim.org/help/3rdparty.htm

I can break these up so the first page is strictly about the code
in BitPim (ie the stuff you list) and second is what you get if
you freeze things.

> I've attached a detailed listing, but the short answer is that I do in
> fact put a handful of files under /usr/lib:

> $ ls -R /usr/lib/bitpim
> /usr/lib/bitpim:
> bmp2avi.lbin*  native/

You can't just put bmp2avi there without also modifying the code
that looks for helper binaries. 

Can you also include a directory listing for /usr/share?  Do you
version the directory (eg /usr/share/bitpim-versionnumber)

You need to be very careful having Python bytecode that is available
across multiple machines.  The format will change between versions
and can be different depending on if the host is 32 or 64 bit,
as well as endianess I believe.  It will try to recompile to new
.pyc/.pyo files but fail because /usr/share is readonly to users.

The FHS does read as BitPim should install in a single directory
below /usr/lib or in /opt.

Roger


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642