Re: debian packaging

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

> It is best to detect that the wrong binaries are present.
> I think it can be done by running ffmpeg --formats,
> looking for the mp3 line and seeing if D and E are there.  We can
> throw up a help page like this:
>
> http://bitpim.org/help/error-nopvconv.htm

Yeah, that would be a step up from the current passive documentation.

>> My preference would be to meet you in the middle: just give the file a
>> distribution-neutral name (such as Makefile or build.sh) and similarly
>> neutral contents and let me specify my preferred directory layout via
>> command-line arguments or environment variables.  That way, you won't
>> have to worry about the details of Debian's packaging policy (which
>> shifts over time), and the contents may be more generally useful.
>
> 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), rather than running swig and building native
code or ensuring that any output has been cleaned up properly.

>> It's probably also worth noting that building Debian packages involves
>> consulting a number of files under the debian/ subdirectory (which,
>> again, you need not provide); 
>
> I'd be happy to make that directory under packaging/.  It will lessen
> the amount of crud you have to carry around.

Thanks, but it is honestly saner to keep the Debian packaging separate
-- see, for instance,
http://lists.debian.org/debian-mentors/2005/04/msg00219.html .

>> several others I didn't bother sending, including changelog, control,
>> and copyright.
>
> I saw you make the changelog using lynx -dump.  That is a good way

Debian packages generally carry two changelogs: a Debian changelog in
a particular standardized format documenting changes to the packaging
and fixes to bugs reported through Debian's bug-tracking system, and
an upstream changelog that gives more detail on the changes to the
actual source code; it's the latter that lynx -dump produces.

> of doing it.  What format is copyright in?  I can put that in packaging
> and then it can also be used for the other packaging systems.

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

> It will be more useful once I add another linuxbuild that makes a
> "source" tree (ie without freezing).  Looking at your rules file,
> it seems like everything is dumped in /usr/share instead of
> /usr/lib as I do for rpm.  You can't put it in /usr/share because
> there is a binary (avi2bin) and that is platform specific.  I am open
> to other locations.  What would be nice is if you could
> post a 'ls -lR' of the tree that you install.

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/

/usr/lib/bitpim/native:
strings/  usb/

/usr/lib/bitpim/native/strings:
__init__.py  __init__.pyc  __init__.pyo  jarow.so

/usr/lib/bitpim/native/usb:
__init__.py   __init__.pyo  libusb.py   libusb.pyo  usb.pyc
__init__.pyc  _libusb.so    libusb.pyc  usb.py      usb.pyo

To support this layout, I give /usr/share/bitpim/native a non-empty
__init__.py:

    # Handle Debian's split-up layout
    __path__.insert(0, '/usr/lib/bitpim/native')

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