Re: debian packaging

"Roger Binns" <[email protected]> writes:

> Mmm.  The source package should be what you start with, not what
> you end up with.  The rpm system definitely works that way.

One can, and often does, take a source package and go from there, but
Debian policy mandates being able to produce one from a working tree,
which I find a lot saner than generating patches by hand each time.
Some packages take the brute-force approach of copying everything to a
subdirectory which can then be wiped out to return to a clean state,
but that's at least not necessary here.

> (eg You don't really want to undo the result of running ./configure)

It really depends on what you're doing.

> 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.

There is if you care about multiple CPU architectures....

> On the license front, BitPim isn't actually pure GPL.  It is GPL
> plus allowing linking to OpenSSL.  (There was a short phase when

Yeah, I include that paragraph in the Debian documentation directory;
such exceptions are fairly common, and I have no problem with them.

> 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.

Version numbers can always be embedded in package names as necessary;
for instance, there are packages named gcc-4.0 and libdb4.4.  I'd
consider that to be overkill for BitPim, though, especially since any
package with a new name requires official ftpmaster approval.

> I believe that is the case.  It would only bite people who distributed
> and ran from only the bytecode. 

OK, then, it doesn't apply here.

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

Right, largely boilerplate, and mostly automatically generated at that
(though I had to start generating the bitpim package's scripts by hand
to force use of -Wignore.

> BTW do you know of anyone running on non-i386?  Everything should

I run on amd64,and haven't hit any 64-bit cleanliness issues AFAICT.
I wouldn't be surprised to learn of users on other non-i386
architectures (particularly good old PowerPC).

> I thought you were dumping bitfling as a seperate package?

I considered that, but held off for now.

>> Description: architecture-dependent helper files for BitFling
>
> I think you mean BitPim there :-)

Yeah, oops.  I have to watch out for those typos. :-)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [email protected] (NOT a valid e-mail address) for more info.


-------------------------------------------------------
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