multiple database support with dbconfig-common : metapackages ?
Hi, i'm working on redmine package, which supports three db types : sqlite, mysql, pgsql and is using dbconfig-common to setup the db. Instead of depending on : sqlite3 | postgresql-client | mysql-client, libdbd-sqlite3-ruby | libdbd-pg-ruby | libdbd-mysql-ruby as bugzilla, drupal, and others do, which i think is confusing the user; is it desirable to do as roundcube package, i.e. providing three metapackages ? Each package providing the correct dependencies for each db type. Then it would give : redmine depends on redmine-mysql | redmine-pgsql | redmine-sqlite On second thought, one would like to have these metapackages : for a php app: - dbconfig-php-mysql | dbconfig-php-pgsql | dbconfig-php-sqlite for a ruby app: - dbconfig-ruby-mysql | dbconfig-ruby-pgsql | dbconfig-ruby-sqlite and so on for other languages. For example, dbconfig-ruby-pg would have these dependencies : libdbd-pg-ruby, postgresql-client Still, managing all the possibilities might create too much metapackages, so it's probably better to stay with the first approach. Thanks for any input on this. Jérémy Lal -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiple database support with dbconfig-common : metapackages ?
On Monday 28 September 2009 15:09:15 Jérémy Lal wrote: Instead of depending on : sqlite3 | postgresql-client | mysql-client, libdbd-sqlite3-ruby | libdbd-pg-ruby | libdbd-mysql-ruby as bugzilla, drupal, and others do, which i think is confusing the user; is it desirable to do as roundcube package, i.e. providing three metapackages ? Each package providing the correct dependencies for each db type. Then it would give : redmine depends on redmine-mysql | redmine-pgsql | redmine-sqlite IANADD, TINASOODP. As a user, I think you are on the right track here. The first set of dependencies would be satisfied by sqlite3 and libdbd-pg-ruby, which might leave redmine installed but completely non-functional. AFAIK, there's no way to express (pkg1 pkg2) | (pkg3 pkg4) without the intervening meta- packages. However, I am a bit surprised that you need to depend on both libdbd-pg-ruby and postgresql-client. Shouldn't libpq5 (desciprion: PostgrSQL client libraries), brought in as a dependency of libdbd-pg-ruby be enough of a client? postgresql-client is only the front-end binaries. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: multiple database support with dbconfig-common : metapackages ?
On 28/09/2009 23:05, Boyd Stephen Smith Jr. wrote: On Monday 28 September 2009 15:09:15 Jérémy Lal wrote: Instead of depending on : sqlite3 | postgresql-client | mysql-client, libdbd-sqlite3-ruby | libdbd-pg-ruby | libdbd-mysql-ruby as bugzilla, drupal, and others do, which i think is confusing the user; is it desirable to do as roundcube package, i.e. providing three metapackages ? Each package providing the correct dependencies for each db type. Then it would give : redmine depends on redmine-mysql | redmine-pgsql | redmine-sqlite IANADD, TINASOODP. As a user, I think you are on the right track here. The first set of dependencies would be satisfied by sqlite3 and libdbd-pg-ruby, which might leave redmine installed but completely non-functional. AFAIK, there's no way to express (pkg1 pkg2) | (pkg3 pkg4) without the intervening meta- packages. The only other way i found to not end up with a non-functional package was to put the three libdbd packages as dependencies, which is not very good either. However, I am a bit surprised that you need to depend on both libdbd-pg-ruby and postgresql-client. Shouldn't libpq5 (desciprion: PostgrSQL client libraries), brought in as a dependency of libdbd-pg-ruby be enough of a client? postgresql-client is only the front-end binaries. I wasn't clear. The package uses dbconfig-common to create database, and dbconfig uses one of those db client packages (sqlite3 | postgresql-client | mysql-client) at config time. The runtime only uses libdbd-(pg|mysql|sqlite3)-ruby. Regards, Jérémy. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upload of a non-latest upstream version?
Hi all, I am packaging a software (tortoisehg) but I have an issues: the latest upstream version (0.8.2) depends on python-iniparse, which has been in ITP for quite a long time. Version 0.8, instead, has not such dependency. Moreover I had to repackage 0.8 to make it debian-policy compliant, while future versions (from 0.8.1) will not need the repackaging. Would it be acceptable to upload 0.8 to the NEW queue and in the meanwhile help to get python-iniparse into Debian? Or is uploading non-latest upstream versions something that must not be done? Thanks, Ludovico -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gnome-inm-forecast (updated package)
Hi Gustavo, On Mon, Apr 06, 2009 at 01:13:30AM +0200, Gustavo Iñiguez Goya wrote: Dear mentors, I am looking for a sponsor for the new version 0.8.0-1 of my package gnome-inm-forecast. It builds these binary packages: gnome-inm-forecast - Spanish weather forecast applet for the GNOME panel The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gnome-inm-forecast - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gnome-inm-forecast/gnome-inm-forecast_0.8.0-1.dsc I would be glad if someone uploaded this package for me. a while ago I began to review this package, but didn't finish, and wasn't able to upload it either way. anyways, I'm now a DD, and willing to sponsor it (assuming you still have interest in it). so please get the packaging up to date (incorporate Chris's NMU, fix any new lintian warnings, check that it builds in pbuilder, etc) and I'll review and upload it for you. Cheers, Ryan -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
Re: Upload of a non-latest upstream version?
Hi, On Mon, Sep 28, 2009 at 03:50:28PM -0700, Ludovico Cavedon wrote: Would it be acceptable to upload 0.8 to the NEW queue and in the meanwhile help to get python-iniparse into Debian? Or is uploading non-latest upstream versions something that must not be done? I am not a DD, but I would be very surprised if this would not be acceptable. You seem to have good reasons to do this and afaik there are no special reasons why the current version is necessary (e.g. as dependency for other packages). Frank Loeffler pgphzJXw92bqE.pgp Description: PGP signature
Re: Upload of a non-latest upstream version?
Ludovico Cavedon ludovico.cave...@gmail.com writes: Would it be acceptable to upload 0.8 to the NEW queue and in the meanwhile help to get python-iniparse into Debian? Or is uploading non-latest upstream versions something that must not be done? As the package maintainer, it's your call what version to package, and the responsibility for that decision falls to you. The latest is preferable, if all else is equal, but as you point out, all else is not equal in this case. If you feel that packaging tortoisehg 0.8 would better serve users than tortoisehg 0.8.2, and are prepared to back that decision up with good reasoning (as you clearly seem to be), I would say go ahead and do it. -- \ “I was sad because I had no shoes, until I met a man who had no | `\ feet. So I said, ‘Got any shoes you're not using?’” —Steven | _o__) Wright | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
