Re: Ole Streicher 2017-09-25 <765c2141-8d1b-44c6-845b-6375d8499...@debian.org>
> This can be addressed by introducing Postgresql-versioned Provides. If
> the q3c package would support f.e. 9.6 and 10, it can have
>
> Provides: postgresql-9.6-q3c, postgresql-10-q3c
>
> If you then need q3c for a s
Hi Christoph,
On 23.09.2017 21:41, Christoph Berg wrote:
> Re: Ole Streicher 2017-09-22
>> I would just do this for my own packages (pqsphere and q3c), which would
>> allow to collect experiences; but ofcourse I don't want to shoot into
>> your feet with the packaging at the postgresql site.
>
>
Re: Ole Streicher 2017-09-22
> Hi Christoph,
>
> may I ping you here? Postgresql-10 just arrived in unstable (great,
> thanks); but I would now rather like to convert to single (and
> bin-NMU-capable) packages instead of adding postgresql-10-q3c now, as it
> is done f.e. for Python packages.
>
>
Hi Christoph,
may I ping you here? Postgresql-10 just arrived in unstable (great,
thanks); but I would now rather like to convert to single (and
bin-NMU-capable) packages instead of adding postgresql-10-q3c now, as it
is done f.e. for Python packages.
I would just do this for my own packages (pqs
Hi Christoph,
On 30.08.2017 15:50, Christoph Berg wrote:
> Re: Ole Streicher 2017-08-30
>> The idea here is to have just one binary package, containing the shared
>> libraries for all supported versions. Extensions are usually small, so
>> combining them in one package will not hurt. So, there wo
Re: Ole Streicher 2017-08-30
> The idea here is to have just one binary package, containing the shared
> libraries for all supported versions. Extensions are usually small, so
> combining them in one package will not hurt. So, there would no
> "postgresql-9.6-q3c" package anymore, d/control.in is
Hi Chriostoph,
On 30.08.2017 14:03, Christoph Berg wrote:
> Re: Ole Streicher 2017-08-30
>> If a new Postgresql version is uploaded (or an old one is removed), a
>> binNMU can be requested, resulting in a new package with the new list of
>> Postgresql objects built in. As it is done for Python or
Re: Ole Streicher 2017-08-30
> For Debian (single Postgresql version) this works well; I don't know
> if "pg_buildext supported-versions" returns them line by line (what I assumed)
> or space-separated (then it needs some adjustments). One should also discuss
> which Postgresql version should be t
Hi,
maybe I do not fully understand the problem here, but isn't that
solvable easily by changing how d/rules is written? As a first strawman
approach, one could do in d/rules (That is for the upcoming
postgresql-q3c package, which is a very simple one):
---8<--
Re: Antonio Terceiro 2017-03-27 <20170327152137.23l7vyrunt5pm...@debian.org>
> We do exactly that in Ruby, and it is manageable. When the set of
> supported versions change, we update the list in a central place
> (ruby-defaults), and binNMU/fix existing modules. We also make the
> dependencies in
On Mon, Mar 27, 2017 at 10:44:22AM +0200, Christoph Berg wrote:
> Re: Antonio Terceiro 2017-03-27 <20170326234116.xkcx7wjcyrqsx...@debian.org>
> > As you said, it has the issue of not helping with upgrades.
>
> True...
>
> > What if, instead of the versioned packages, you provided unversioned
> >
Re: Antonio Terceiro 2017-03-27 <20170326234116.xkcx7wjcyrqsx...@debian.org>
> As you said, it has the issue of not helping with upgrades.
True...
> What if, instead of the versioned packages, you provided unversioned
> package names, and each package contained one .so for each supported
> Postgr
On Sun, Mar 26, 2017 at 07:02:04PM +0200, Christoph Berg wrote:
> Re: Antonio Terceiro 2017-03-26 <20170326115924.zykotnwecwpr2...@debian.org>
> > I don't exactly get why having a package postgresql-debversion that
> > depends on the postgresql-X.Y-debversion corresponding to the current
> > X.Y wo
Re: Antonio Terceiro 2017-03-26 <20170326115924.zykotnwecwpr2...@debian.org>
> I don't exactly get why having a package postgresql-debversion that
> depends on the postgresql-X.Y-debversion corresponding to the current
> X.Y would not work. server and client themselves are already managed
> like th
On Sat, Mar 25, 2017 at 07:58:54PM +0100, Christoph Berg wrote:
> Control: tags -1 moreinfo
>
> Re: Antonio Terceiro 2017-03-14 <2017031423.xupt5eddlfw5i...@debian.org>
> > At the moment I am automating the installation of postgresql and and the
> > debversion extension. The fact that there is
Control: tags -1 moreinfo
Re: Antonio Terceiro 2017-03-14 <2017031423.xupt5eddlfw5i...@debian.org>
> At the moment I am automating the installation of postgresql and and the
> debversion extension. The fact that there is no "unversioned" binary
> package makes that harder than necessary: I wil
Source: postgresql-debversion
Severity: wishlist
At the moment I am automating the installation of postgresql and and the
debversion extension. The fact that there is no "unversioned" binary
package makes that harder than necessary: I will have to hardcode
postgresql-X.Y-debversion, and as soon as
17 matches
Mail list logo
