Re: bitpim binary modules breaks Gentoo QA policies

> not going to happen. I'm not willing to take this extra-work every time
> I bump the version.

Err, ebuild already has a module that does this.  You don't have to change
anything on each release:

==== 8< ====
# Source is distributed only by CVS
# We will check out a particular revision
ECVS_AUTH="pserver"
ECVS_SERVER="cvs.sourceforge.net:/cvsroot/${PN}"
ECVS_MODULE="${PN}"
ECVS_BRANCH="BITPIM_${PV//./_}"
ECVS_USER="anonymous"
ECVS_PASS=""
ECVS_CVS_OPTIONS="-dP"

inherit cvs
==== 8< ====

If you have that in your ebuild then it will automatically grab the right
source.  Of course the next release will need to use Subversion instead
but the principle is the same.  Look at this:

http://cvs.sf.net/viewcvs.py/bitpim/bitpim/unixpkg/bitpim.ebuild

The reason that didn't go any further is because the person who supplied
it couldn't get the other packages (eg wxPython) to be maintained
and updated.

> c'mon, all the other open source projects release their source tarball
> first! that is the way things work in this realm.
> is it so hard to upload just one more file?

I don't see you volunteering for this extra effort.  I am not going to
do it.  There is zero benefit to the users of a source tarball - the
source is sitting there in CVS and the users don't run from source.  There 
is zero benefit to developers since they will need to keep up to date
with changes.

The only benefit is to packagers.  And we have already established that
they are not interested in keeping up or ensuring their users have
recent versions.

In fact the only packager who does keep up is me, putting up something
that is built on Redhat 9 and runs on all recent popular distros.  And
I already have the source.

> then you want us remove app-mobilephone/bitpim from our tree, leaving
> Gentoo users install it from your rpm?

It should either be maintained or removed.  Having something that is
mostly ignored and out of date doesn't help anyone.  It is especially
silly having it be something that just untars the rpm *and* have it
being out of date.(@)

I have volunteered to help "fix" all this, but it requires ongoing effort
from a Gentoo developer.

IMHO Gentoo can't cope with something that does change fairly frequently
even though people may think it does.  (I've found this with a few other
packages as well.)

On the other hand, I am still waiting for a reply to my response to a 
Debian developer in 2004 :-)

(@) What might be better is having a tool that given an rpm, untars
it, and installs it automatically updating the package database.
That tool won't need to be updated very often and users could just
run it when they have a new rpm.  

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