Re: bitpim binary modules breaks Gentoo QA policies

I was the original author of BitPim (now a team of several)
and wrote/maintain the build and packaging system, as well as
make the releases.  I also happen to be a user of Gentoo for 
several years.

BitPim itself is written in Python, but needs a variety of
binary packages.  One example is the wxPython windowing
system.  Another is APSW (used for SQLite) and an interface
to libusb.

Since I don't expect users to install Python, wxPython,
compile several extensions etc to run BitPim (why should
they care what language it is written in?) I provide binary
packages for download.  Under the hood, these are a directory
structure containing the Python interpretter, the Python bytecode
in a zip file, assets (icons, splashscreens, online help etc)
and dlls for the binary extensions.

Since every version of every Linux distro has different versions
of different libraries and random other quirks, the Linux
binary package is made on Redhat 9.  Pretty much everything
can run Redhat 9 binaries, sometimes needing compat glibc.
The SourceForge file release process is so tedious and annoying
that I won't build and upload on more Linux platforms (ie
VmWare won't help).

As for this textrel message, I really don't care.  The package
does work and that is what I care about.  On the main web page
you can see that I tell people using Gentoo to just use rpm.

The correct fix and the Gentoo philosophy is that this should
be run/built from "source".  However there are several problems.
Firstly the Gentoo release procedures cannot keep up.  There
is a new BitPim release every three weeks (it used to be every two).
Consequently things will be long obselete by the time ~x86 is
removed.

The second problem is that ebuilds have to be put in place for
a number of other packages that belong to other herds.  Some
already exist but are really badly maintained.  For example
the wxPython ebuild is still tied to 2.4 (the last version
of that was released in 2003) and the 2.6 ebuild doesn't
produce something that works.

Given these problems with portage, someone started making
ebuilds that just grab the rpm and untar it.  Even then 
they haven't keep up with the release schedule.

Unless someone at Gentoo is prepared to own the effort and
put proper time into this, then I am not going to do anything 
differently.  

If someone will do that, then they need to do the following.
I will give them full assistance, and also make some code
changes that will help.  Doing this will also get you
BitPim working on all architectures (there are no CPU or
32/64 bit dependencies)

- Stay on top of the BitPim release schedule.  I am prepared
  to have a template ebuild in the source tree (in fact there
  already is one) and run a command that makes a release one
  and mails it to someone.  If you aren't going to keep up
  with the BitPim releases then having anything in portage
  is unfair to the users (the current rpm process works fine)

- Create and push through ebuilds for several of the
  extensions used, as well as keep them up to date.  (They
  don't change that often).  Altenatively you can make
  a build system that builds private uptodate copies
  of the extensions and keeps them in the BitPim deployment
  directory

- BitPim has automatic checks for updates.  Behind the scenes
  this is done by grabbing an xml file off the web server and
  doing pattern matching.  I am prepared to change the code
  to make it so that the update functionality is hidden if
  built on Gentoo, or that it grabs the xml file from a Gentoo
  server, or that Gentoo specific xml information is kept on
  the site with Gentoo built versions looking for that.

The above is all about how to fix this properly (or not bother).
Here are the answers to what you asked in the mail:

> TEXTREL usr/lib/bitpim-0.8.08/apsw.so
> TEXTREL usr/lib/bitpim-0.8.08/native.usb._libusb.so

These are built using Python on Redhat 9 and use whatever
linker options are standard for that.

> I'd take a look at this but I can't seem to find
> the source code in the sf bitpim cvs repo

We switched to Subversion last night.  You can find details
at http://sourceforge.net/svn/?group_id=75211
The usb stuff is in trunk/bitpim/src/native/usb.  apsw is
currently stored elsewhere (Google it).  It will be moving
into the subprojects part of the BitPim Subversion.  In
either case there is nothing you can do to the code to
change the message - you have to fix distutils on Redhat 9.

> executable stacks
> RWX --- --- usr/lib/bitpim-0.8.08/helpers/bmp2avi.lbin
> RWX --- --- usr/lib/bitpim-0.8.08/helpers/pngtopnm.lbin
> RWX --- --- usr/lib/bitpim-0.8.08/helpers/pnmtopng.lbin
> RWX --- --- usr/lib/bitpim-0.8.08/helpers/ppmquant.lbin

These are built on Redhat 9.  Yadda yadda yadda.  To fix the
first one would require BitPim to be compiled on Gentoo.
The bottom three are from netpbm.  The code could be changed
to look in the helpers directory, and if they are not there
then look on the system and then have netpbm listed as a
dependency.  If BitPim does end up being built on Gentoo
then I'll make this change.

Basically, if a Gentoo developer is prepared to put the 
effort into making several things up to date and keep them
that way then I'll help.  If not, you get what is built
on Redhat 9 just like all the other Linux distros.

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