libqof1 currently breaks Policy 8.2 by having Architecture: all files in the shared library package. A SONAME transition is also imminent for QOF upstream. The only package that does not currently build against the upstream VCS code for libqof2 is gnotime and I've submitted patches upstream to fix that problem. One other QOF reverse dependency has the same issue with Policy 8.2 - libqofexpensesobjects0 from gpe-expenses. The other reverse dependency of libqof1 is pilot-qof. Both gpe-expenses and pilot-qof build cleanly (and have been tested at runtime) against the libqof2 upstream code *but* are not actually binNMU safe in Debian because of the need to also change the name of the backend plugins (libqof-backend-qsf0 becomes libqof2-backend-qsf and libqof-backend-sqlite0 becomes libqof2-backend-sqlite). I propose to: 1. Upload libqof1 0.7.5-2 (or possibly an upstream 0.7.6-1 branch) that creates a new package, qof-data to comply with Policy 8.2 and a set of new virtual packages (qof-backend-xml and qof-backend-sqlite - possibly qof-backend-gda) that are Provide:'d by the new backend plugins. (Applications depending on libqof1 or libqof2 are free to choose the storage mechanism used by QOF by specifying at least one backend and allowing the user to specify an "access method" like file:// or sqlite://). 2. Upload new upstream versions of gpe-expenses and pilot-qof that depend on the virtual backend package(s) instead of the actual backend names to make pilot-qof and gpe-expenses binNMU safe for the imminent QOF transition. Fix the issue with libqofexpensesobjects0 in the same gpe-expenses upload by adding a new package, libqofexpensesobjects-data. 3. Wait for Goedson to get a new release of gnotime into Debian with the upstream patches for libqof2, if that hasn't happened before packages from 1 and 2 clear NEW. 4. Upload libqof2 (QOF 0.8.0) and ask for binNMU's of gnotime, pilot-qof and gpe-expenses. Stages 1 and 2 will involve trips through NEW (the new upstream release of pilot-qof also introduces a few new packages). Please advise whether any of these stages need to wait for current or upcoming transitions and whether the plan itself is acceptable. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgppEdF6kGDSM.pgp
Description: PGP signature