Re: Re: debian packaging

>> packaging/buildmodules.py
> 
> Nice.  This helps somewhat; however, it provides no way to get back to
> a pristine source tree (not *that* difficult, mind you, but a
> necessary step in producing the source package) 

Mmm.  The source package should be what you start with, not what
you end up with.  The rpm system definitely works that way.
(eg You don't really want to undo the result of running ./configure)

> and also completely ignores bmp2avi.

I view bmp2avi as an external helper binary.  It just so happens
that the source is part of BitPim.  The code hasn't changed in
the last year.  There isn't any need to rebuild it all the time.
I'll ponder this one some more.

> It also doesn't install anything anywhere, though I suppose that's
> what makedist.py is theoretically for.

Correct.  Makedist needs another method added that makes an install
tree suitable for slurping up by the Debian tools.

On the license front, BitPim isn't actually pure GPL.  It is GPL
plus allowing linking to OpenSSL.  (There was a short phase when
I attempted to use OpenSSL to talk to BitFling and changed the 
license accordingly.  It would be way too hard to contact all
people to remove that relaxation now.)  On Mac and Linux, OpenSSL
is distributed with the OS and the GPL allows linking with that
anyway so this distinction is immaterial.

> I thought I did last time, but it appears to have been eaten.  I'll
> tack on an inline copy this time around.

Last time it was only part of what got installed.

> No, I see no reason to version any directories, as only one version of
> a given .deb can be installed at a time anyway.

Really?  That seems to be a pretty major restriction!  All the 
other packaging systems I am familiar with do allow mulitple
versions to be installed.  This is used for example to have
gcc3 and gcc4 on the same system, or multiple concurrent versions
of Berkeley DB.

> I was under the impression that the bytecode was machine-independent.
> Even if not, though, I'm fairly certain that Python will simply ignore
> incompatible or outdated bytecode files that it can't update.

I believe that is the case.  It would only bite people who distributed
and ran from only the bytecode. 
 
>     649 bytes,    19 lines   *  postinst             #!/bin/sh
>     160 bytes,     5 lines   *  postrm               #!/bin/sh
>     103 bytes,     9 lines   *  prerm                #!/bin/sh

Anything existing in those (I assume they deal with the bytecode
compilation and removal).

> Architecture: all

BTW do you know of anyone running on non-i386?  Everything should
work fine (we run on differently endianess Mac/PPC without problem).

> bitfling_0.8.11.dfsg.1-1_all.deb

I thought you were dumping bitfling as a seperate package?

> bitpim-lib_0.8.11.dfsg.1-1_i386.deb
> -----------------------------------
> Description: architecture-dependent helper files for BitFling

I think you mean BitPim there :-)

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