Обсуждение: Re: pgtap in our apt repo

Re: Jon Erdman 2015-05-25 <20150525135518.4ceacdf62cbecab69b53f9f2@bluetreble.com>
>
> .deb (binary-indep) built against 9.4, and deb-src attached.
>
> The problem here is that this package is set up to only work against one pg version at a time. We'll need to change
that...probablyby appending -9.x to the package version and making multiple debs :( 
>
> Anyone have a better idea?

For an arch:all package you could stuff all extensions into a single
package and make symlinks for the duplicated files. I've done that for
... *search disk* ... pgagent.

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

On Mon, 25 May 2015 21:03:41 +0200
Christoph Berg <myon@debian.org> wrote:

> > Anyone have a better idea?
>
> For an arch:all package you could stuff all extensions into a single
> package and make symlinks for the duplicated files. I've done that for
> ... *search disk* ... pgagent.

Problem is, I'm not *certain* the .sql files in the extensions dir really are version agnostic. I'd have to build it
for9.1-4 and compare them. 
--
Jon Erdman <jon.erdman@bluetreble.com>
Sr. Data Engineer, Blue Treble Solutions, LLC
312.285.6735

On May 25, 2015, at 12:26 PM, Jon Erdman <jon.erdman@bluetreble.com> wrote:

> Problem is, I'm not *certain* the .sql files in the extensions dir really are version agnostic. I'd have to build it
for9.1-4 and compare them. 

They are not. Notably, the pg_version() function gets the version added to it by configure. Other than that, you can
seehow the files vary by version by looking at the patches in compat. There are patches for 8.0-9.0, but not since 9.0.
Ifyou’re only on 9.1 or above, only pg_version() changes. 

Best,

David

On May 26, 2015, at 11:57 AM, Jon Erdman <jon.erdman@bluetreble.com> wrote:

> Hmm, what about in the future though? I think it might be better to go like skytools and have a common + per version
package(for the extension sql). That assumes there's anything to go into a -common pkg... 

I don’t understand what you’re asking me. :-(

D

On 05/25/2015 09:03 PM, Christoph Berg wrote:
> For an arch:all package you could stuff all extensions into a single
> package and make symlinks for the duplicated files. I've done that for
> ... *search disk* ... pgagent.

Interesting.. just a couple days ago I started to work on PGAPT-ing
pgtap as well. As with other packages before, I think the hardest part
is to make the Makefile VPATH aware. I intend to file a patch upstream,
soon-ish. Next step: autopkgtesting.

Regarding packaging: I don't think there's enough flesh to warrant a
-common package, as the per-Pg-package weigh in at around 90K. I'm
considering a separate -doc package, though. (Barely heavier, either.)

Also note that pgtap already is in Debian (well, has been). I contacted
the current maintainer (Pierre Chifflier AKA pollux), but didn't get
feedback on how he prefers me to contribute. Pierre?

Myon: Am I correct that PGAPT needs a git repo to fetch from? Or can we
handle other sources, there?

Regards

Markus Wanner

Re: Markus Wanner 2015-05-26 <5564D712.4080706@bluegap.ch>
> Also note that pgtap already is in Debian (well, has been). I contacted

(It's still in unstable.)

> Myon: Am I correct that PGAPT needs a git repo to fetch from? Or can we
> handle other sources, there?

generate-pgdg-source can build from git, svn, and bzr, or just use the
package as-is from unstable. Support for other VCSes depends on what
jenkins-job-builder supports, or for what git-* wrappers exist.

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

On Tue, 26 May 2015 22:26:58 +0200
Markus Wanner <markus@bluegap.ch> wrote:

> On 05/25/2015 09:03 PM, Christoph Berg wrote:
> > For an arch:all package you could stuff all extensions into a single
> > package and make symlinks for the duplicated files. I've done that for
> > ... *search disk* ... pgagent.
>
> Interesting.. just a couple days ago I started to work on PGAPT-ing
> pgtap as well. As with other packages before, I think the hardest part
> is to make the Makefile VPATH aware. I intend to file a patch upstream,
> soon-ish. Next step: autopkgtesting.
>
> Regarding packaging: I don't think there's enough flesh to warrant a
> -common package, as the per-Pg-package weigh in at around 90K. I'm
> considering a separate -doc package, though. (Barely heavier, either.)
>
> Also note that pgtap already is in Debian (well, has been). I contacted
> the current maintainer (Pierre Chifflier AKA pollux), but didn't get
> feedback on how he prefers me to contribute. Pierre?

Markus, did you notice that I took the existing deb-src package (0.90.0) from debian, and used uupdate to pull in the
0.95.1source and rebuild against 9.4 on Ubuntu 14.04? In fact, I'll forward all of you the message now. It worked fine,
sowe shouldn't need to create our own. All we need to do is decide if this existing package should try to put the
extensionfiles automagically in all expected locations for all installed versions (not fool-proof), or instead make
pgtap-9.1-9.2, etc. packages built against (and requiring each version of pg) which I think is the more correct thing
todo.  

One since source package, that ala skytools, builds a .deb for each version of pg it detects as installed on the build
hostautomagically.  

The contents of the one I built look like this:

jon@stuck:~/debs$ dpkg-deb -c pgtap_0.95.1-0ubuntu1_all.deb
drwxr-xr-x root/root         0 2015-05-25 14:22 ./
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/share/
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/share/postgresql/
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/share/postgresql/9.4/
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/
-rw-r--r-- root/root    298473 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap--0.95.0.sql
-rw-r--r-- root/root    183173 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap-schema--0.95.0.sql
-rw-r--r-- root/root     54374 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap--0.91.0--0.92.0.sql
-rw-r--r-- root/root     16657 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap--0.94.0--0.95.0.sql
-rw-r--r-- root/root    115279 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap-core--0.95.0.sql
-rw-r--r-- root/root      5504 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap--0.93.0--0.94.0.sql
-rw-r--r-- root/root       177 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap.control
-rw-r--r-- root/root     47343 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap--unpackaged--0.91.0.sql
-rw-r--r-- root/root     20921 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap--0.92.0--0.93.0.sql
-rw-r--r-- root/root       731 2015-05-25 14:22 ./usr/share/postgresql/9.4/extension/pgtap--0.90.0--0.91.0.sql
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/share/doc/
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/share/doc/postgresql-doc-9.4/
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/share/doc/postgresql-doc-9.4/extension/
-rw-r--r-- root/root     45898 2015-05-25 14:22 ./usr/share/doc/postgresql-doc-9.4/extension/pgtap.mmd.gz
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/share/doc/pgtap/
-rw-r--r-- root/root      1332 2011-06-11 09:40 ./usr/share/doc/pgtap/copyright
-rw-r--r-- root/root      1231 2015-05-25 14:22 ./usr/share/doc/pgtap/changelog.Debian.gz
-rw-r--r-- root/root     45898 2015-05-25 14:22 ./usr/share/doc/pgtap/pgtap.mmd.gz
drwxr-xr-x root/root         0 2015-05-25 14:22 ./usr/bin/
jon@stuck:~/debs$


> Myon: Am I correct that PGAPT needs a git repo to fetch from? Or can we
> handle other sources, there?
>
> Regards
>
> Markus Wanner
--
Jon Erdman <jon.erdman@bluetreble.com>
Sr. Data Engineer, Blue Treble Solutions, LLC
312.285.6735

On May 26, 2015, at 9:30 PM, Jon Erdman <jon.erdman@bluetreble.com> wrote:

> I was asking if there might ever be a point at which there *would* be per-version differences and therefore
per-versionpackaging would be better. I think it's the way to go, honestly. 

That’s how the RedHat RPMs are cut.

David

On Tue, 26 May 2015 12:06:11 -0700
"David E. Wheeler" <david@justatheory.com> wrote:

> On May 26, 2015, at 11:57 AM, Jon Erdman <jon.erdman@bluetreble.com> wrote:
>
> I don’t understand what you’re asking me. :-(

I was asking if there might ever be a point at which there *would* be per-version differences and therefore per-version
packagingwould be better. I think it's the way to go, honestly. 
--
Jon Erdman <jon.erdman@bluetreble.com>
Sr. Data Engineer, Blue Treble Solutions, LLC
312.285.6735

Jon,

On 05/26/2015 11:09 PM, Jon Erdman wrote:
> Markus, did you notice that I took the existing deb-src package (0.90.0) from debian, and used uupdate to pull in the
0.95.1source and rebuild against 9.4 on Ubuntu 14.04? 
No, I just saw this thread and responded, but didn't review any package,
yet.
> In fact, I'll forward all of you the message now. It worked fine, so we shouldn't need to create our own.
Agreed. As I pointed out, I think we should coordinate with the existing
maintainer (and I would hope to migrate the packaging to some kind of
VCS repo).
> All we need to do is decide if this existing package should try to put the extension files automagically in all
expectedlocations for all installed versions (not fool-proof), or instead make pgtap-9.1 -9.2, etc. packages built
against(and requiring each version of pg) which I think is the more correct thing to do. 
Yes, I think so, too. As David pointed out, the SQL files do not
necessarily match. If we want to go through the effort of de-duplicating
them, we need to be very careful. Let's start simple.

Regards

Markus Wanner

On Wed, 27 May 2015 07:29:00 +0200
Markus Wanner <markus@bluegap.ch> wrote:

> Agreed. As I pointed out, I think we should coordinate with the existing
> maintainer (and I would hope to migrate the packaging to some kind of
> VCS repo).

FYI From earlier that might not have made it to the mailing list, don't hold your breath about getting a response from
thecurrent maintainer: 

On Mon, 25 May 2015 16:18:58 +0200
Christoph Berg <myon@debian.org> wrote:

>> The fix is probably simple, but someone needs to do it, and possibly
>> become the new maintainer, Pierre doesn't seem to be interested atm.
>>
>> Christoph

--
Jon Erdman <jon.erdman@bluetreble.com>
Sr. Data Engineer, Blue Treble Solutions, LLC
312.285.6735

On 05/27/2015 05:07 PM, Jon Erdman wrote:
> On Mon, 25 May 2015 16:18:58 +0200
> Christoph Berg <myon@debian.org> wrote:
>
>>> The fix is probably simple, but someone needs to do it, and possibly
>>> become the new maintainer, Pierre doesn't seem to be interested atm.

@Jon: thanks for forwarding.

Regarding Mr. Someone: I just stepped forward and setup the repository here:

http://anonscm.debian.org/gitweb/?p=pkg-postgresql/pgtap.git

It adds proper decoupling for per-Postgres-major-version packages. Given
there's no real "build", I'm not quite sure the vpath-build approach was
the best idea.

@David: could you please have a look at the vpath patch here:
http://anonscm.debian.org/cgit/pkg-postgresql/pgtap.git/tree/debian/patches/vpath.diff

As I mentioned before, autopkgtests are still missing. I'm looking into
it, shortly.

Regards

Markus

On May 27, 2015, at 12:41 PM, Markus Wanner <markus@bluegap.ch> wrote:

> @David: could you please have a look at the vpath patch here:
> http://anonscm.debian.org/cgit/pkg-postgresql/pgtap.git/tree/debian/patches/vpath.diff

That looks fine, except for the directories.stamp target, which I don’t understand.

David

On 05/27/2015 09:49 PM, David E. Wheeler wrote:
> On May 27, 2015, at 12:41 PM, Markus Wanner <markus@bluegap.ch> wrote:
>
>> @David: could you please have a look at the vpath patch here:
>> http://anonscm.debian.org/cgit/pkg-postgresql/pgtap.git/tree/debian/patches/vpath.diff
>
> That looks fine, except for the directories.stamp target, which I don’t understand.

I originally intended it to only carry the required 'mkdir' commands.
Then I figured that some .sql files aren't generated, but just expected
to be there, in the sql directory (by some wildcard pattern). To have
them in the build directory, I added the cp line, there, which works for
VPATH builds, but probably not for normal ones. This certainly needs
cleanup. Ideally, we wouldn't need copies at all.

/me puts on his Make-Fu robe.

Regards

Markus