Mass filing wish list bugs against package depending on dbconfig-common [WAS: Re: dbconfig-common: near future change in dependency stack]

Hi all, The new style dbconfig-common packages live already for some time in the archive, and I haven't received any complaint/bug yet about the database dependent packages. This means that I believe it is time to bug the maintainers of packages that depend on dbconfig-common with a wish list bug

Re: dbconfig-common: near future change in dependency stack

Excerpts from The Wanderer's message of 2016-01-30 15:49:51 -0800: > On 2016-01-30 at 08:49, Clint Byrum wrote: > > > Excerpts from The Wanderer's message of 2016-01-30 04:28:42 -0800: > > > >> On 2016-01-30 at 04:51, Paul Gevers wrote: > > >>> Actually, I don't think that is in scope of

Re: dbconfig-common: near future change in dependency stack

Hi all, On 06-12-15 14:23, Paul Gevers wrote: > For those of you that backport their packages via the Debian backports > archive, I will provide a backport of dbconfig-common once version 2.0.0 > reaches testing. This has happened. dbconfig-common, dbconfig- and dbconfig-no-thanks are now in

Re: dbconfig-common: near future change in dependency stack

Hi, On 30-01-16 12:30, PICCA Frederic-Emmanuel wrote: >> If a package relies on the dbconfig-common framework for database setup >> and maintenance, installing dbconfig-no-thanks instead of one of >> dbconfig's database-specific packages will block this function. It is >> intended for cases where

Re: dbconfig-common: near future change in dependency stack

Hi Frederic-Emmanuel, On 30-01-16 09:30, PICCA Frederic-Emmanuel wrote: > I am the maintainer of tango-db which use dbconfig-common and a mysql > database. > It seems that there is currently a discussion about he support of mysql and > mariadb for Debian 9 Can you please point me to the

Re: dbconfig-common: near future change in dependency stack

On 2016-01-30 at 04:51, Paul Gevers wrote: > Hi Frederic-Emmanuel, > > On 30-01-16 09:30, PICCA Frederic-Emmanuel wrote: >> Do you know if dbconfig-common will integrate a way to switch from >> mysql to mariadb in the near futur. something whcih can help do the >> migration database from mysql

Re: dbconfig-common: near future change in dependency stack

Excerpts from The Wanderer's message of 2016-01-30 04:28:42 -0800: > On 2016-01-30 at 04:51, Paul Gevers wrote: > > > Hi Frederic-Emmanuel, > > > > On 30-01-16 09:30, PICCA Frederic-Emmanuel wrote: > > >> Do you know if dbconfig-common will integrate a way to switch from > >> mysql to mariadb

Re: dbconfig-common: near future change in dependency stack

On 2016-01-30 at 08:49, Clint Byrum wrote: > Excerpts from The Wanderer's message of 2016-01-30 04:28:42 -0800: > >> On 2016-01-30 at 04:51, Paul Gevers wrote: >>> Actually, I don't think that is in scope of dbconfig-common. I >>> would rather expect that MariaDB would provide that >>>

Re: dbconfig-common: near future change in dependency stack

Hi Zigo, On 10-12-15 01:12, Thomas Goirand wrote: > Now, what should I do if my packages support all types of db currently > supported by dbconfig-common (ie: sqlite, mysql and postgress)? Wasn't my example in the first e-mail clear? I would expect: Depends: dbconfig-sqlite | dbconfig-sqlite3 |

Re: dbconfig-common: near future change in dependency stack

Mathias Behrle dijo [Tue, Dec 08, 2015 at 10:16:38AM +0100]: > Some questions for Tryton server: > > The situation is > > - Tryton server runs out of the box without configuration with a SQLite > database > - The (strongly) recommended database is PostgreSQL, but there is also support > for

Re: dbconfig-common: near future change in dependency stack

On 12/06/2015 06:22 PM, Clint Byrum wrote: > Excerpts from Paul Gevers's message of 2015-12-06 05:23:07 -0800: >> Hi all, >> >> TL;DR;1 if your package depends on dbconfig-common please update your >> dependencies when my version 2.0.0 hits the archive (I expect in two >> weeks). >> TL;DR;2 should

Re: dbconfig-common: near future change in dependency stack

On 12/06/2015 02:23 PM, Paul Gevers wrote: > As a bonus, I can now add the database server packages to recommends, > which should make life of the less experienced user easier. Do you think > I should do this, or should I leave the database server package at the > suggests level? Please don't put

Re: dbconfig-common: near future change in dependency stack

* Paul Gevers: " dbconfig-common: near future change in dependency stack" (Sun, 06 Dec 2015 14:23:07 +0100): Hi Paul, > TL;DR;1 if your package depends on dbconfig-common please update your > dependencies when my version 2.0.0 hits the archive (I expect in two > weeks

Re: dbconfig-common: near future change in dependency stack

Le 06/12/2015 20:48, Paul Gevers a écrit : > I am totally flabbergasted. dbconfig-common goes through a lot of hoops > just to make sure this is not true. Sure, the *default* questions and > answers are geared towards local database servers. But by either > (re-)configuring dbconfig-common to

Re: dbconfig-common: near future change in dependency stack

Hi Mathias, On 08-12-15 10:16, Mathias Behrle wrote: > Would it be possible for the last point to skip completely the database > configuration (e.g. dbconfig* not jumping in at all, when tryton-neso pulls in > tryton-server)? I believe this is something that you would need to implement inside

Re: dbconfig-common: near future change in dependency stack

Hi Vincent, On 08-12-15 09:49, Vincent Danjean wrote: > When local configuration does not work or when local databases cannot > be reached or when local database server packages are not installed > the priority of dbconfig-common question about remote database should > be modified so that the

Re: dbconfig-common: near future change in dependency stack

Le 08/12/2015 20:25, Paul Gevers a écrit : > I assume you don't like the dbconfig-pgsql | dbconfig-mysql | > dbconfig-no-thanks dependency alternatives? By default the user will > then get pgsql. Not if the user has dbconfig-mysql or dbconfig-no-thanks already installed (probably due to other

Re: dbconfig-common: near future change in dependency stack

Le 08/12/2015 20:14, Paul Gevers a écrit : > Hi Vincent, > > On 08-12-15 09:49, Vincent Danjean wrote: >> When local configuration does not work or when local databases cannot >> be reached or when local database server packages are not installed >> the priority of dbconfig-common question about

Re: dbconfig-common: near future change in dependency stack

❦ 6 décembre 2015 14:23 +0100, Paul Gevers  : > TL;DR;2 should the new dbconfig- packages recommend or suggest > the database server packages? Suggest. Otherwise, your plan looks just fine. -- All generalizations are false, including this one. -- Mark Twain

Re: dbconfig-common: near future change in dependency stack

Excerpts from Paul Gevers's message of 2015-12-06 05:23:07 -0800: > Hi all, > > TL;DR;1 if your package depends on dbconfig-common please update your > dependencies when my version 2.0.0 hits the archive (I expect in two > weeks). > TL;DR;2 should the new dbconfig- packages recommend or suggest >

dbconfig-common: near future change in dependency stack

Hi all, TL;DR;1 if your package depends on dbconfig-common please update your dependencies when my version 2.0.0 hits the archive (I expect in two weeks). TL;DR;2 should the new dbconfig- packages recommend or suggest the database server packages? Since I took over the dbconfig-common package I

Re: dbconfig-common: near future change in dependency stack

Excerpts from Paul Gevers's message of 2015-12-06 11:48:41 -0800: > Hi Clint, > > On 06-12-15 18:22, Clint Byrum wrote: > > I've never been very happy with > > dbconfig-common because it kind of assumes databases are on the same > > server as apps, which is increasingly not the case with smaller

Re: dbconfig-common: near future change in dependency stack

Hi Clint, On 06-12-15 18:22, Clint Byrum wrote: > I've never been very happy with > dbconfig-common because it kind of assumes databases are on the same > server as apps, which is increasingly not the case with smaller server > instances running in VMs, on the cloud and in containers. I am