Thread: Packaging automation, testing and work-reduction
Hi all I'm interested in getting more involved in the RPM packaging process for PostgreSQL. I know I'm new to the scene, so the following might be jumping the gun a bit, but I'm also aware that it's hard to find time for PGDG RPM work and more contribution might be valued. I've produced new spec files for PostgreSQL 9.4 that unify all of EL-5/6/7 and Fedora 19/20/21 into a single spec that can be rebuilt for each platform, and I think that's ready for wider testing now. Builds for all platforms work correctly using 'mock' on a Fedora 20 build-host, and they test-install into the target platform correctly, and interoperate with existing PGDG RPMs. I've fixed a number of packaging bugs in the process. I'll attach the spec and the rest of the RPM sources in a followup mail to the "unifying the spec files" thread. I'm looking at future steps now, and I'd like to outline some ideas that might make PGDG RPMs easier to maintain, more friendly toward contribution from others, more reliable, easier to test, and more inter-operable with other repositories. My personal motivation - just so I'm upfront about this - is that what I'm talking about would make it a *lot* easier for me to produce "hotfix" RPMs for 2ndQuadrant customers who want fixes backported before a new minor release, produce backport RPMs where they want something backported into 9.2 or whatever, produce RPMs for customers with perf/bug fixes that haven't been accepted by upstream yet, and make packaging BDR a lot easier too. From my understanding of how things currently work I think it'd also make it easier to maintain PGDG, but of course I don't have much history here or the experience with the current process to really back that. I'd like to (short version): * Depend on EPEL (some packages already do, it's just not declared) * Drop packages from PGDG that're already in EPEL * Unify spec files for different dists * Build with Mock * Use Koji * Test with Mock * Let Koji handle createrepo etc * Move package management to git Details of what I'm suggesting: - Depend on EPEL for RHEL/CentOS/SciLinux and remove all packages provided by EPEL from PGDG to reduce duplication and potential for conflicts. (This might involve applying for EPEL dev status eventually, but shouldn't to start with). As many packages would work w/o EPEL I doubt it'd have to be a hard dependency. Just say that EPEL is recommended and will be required for some packages. - Progressively unify spec files for other packages to remove the need for individual specs for each target OS, like I've already done for postgresql94. (Done for Pg 9.4, not prior, but see next item). - For PostgreSQL packages also make the major versions supported in the same define, just by changing the macros. So packaging bug fixes are easier. (I haven't done this, but it doesn't look too hard). - Always build packages using mock, so issues with build-depends and undeclared runtime dependencies like those I've recently reported are identified at build time. (This works with the packages I've rewritten). Use mock target definition files that include EPEL repositories for EL targets. - Test-install packages in another mock chroot after building, and run some basic tests - initdb, etc, at least. Trivial to automate, just run a script within the mock chroot. (I've done part of this and it's not hard to finish off). - Automate package building with mock via Koji by setting up a Koji server for PGDG. This is fairly well documented, and really just needs a host with a pile of disk space, preferably running a new Fedora release. Builds can then be submitted to Koji, either as SRPMs or via pushes to git. The latter involves tarballs in git, but that's what Fedora does. Koji can pull the packages from Fedora and EPEL to use as a base for builds, but (using Mock) will only install and enable those declared for dependencies or build-depends in any individual build. I haven't set a Koji up, but I'd very much like to. If PGDG wants to go this way I'll be happy to do it for PGDG, rather than creating a private Koji. Check out: http://koji.fedoraproject.org/koji/ https://fedorahosted.org/koji/ 'mash' is used to manage koji -> yum repo work. - Let Koji take care of running createrepo, repoview, etc as updates are pushed, rather than running the manually; - Test repositories with repoclosure and complain if we find dependencies that can't be satisfied, e.g. repoclosure -l fedora -l pgdg94 or repoclosure -l el5 -l epel5 -l pgdg91 (with a corresponding yum configuration). This can be done within 'mock', or with individual yum config files rather than using the system ones. Thoughts? It probably makes sense to fire up a Koji instance first. Then start progressively getting packages building with corrected build-depends and depends, using mock, and where possible unified to build the same spec on all dists, moving them into Koji-friendly git management as that happens. As packages are updated, the copy in svn would want to be updated to match so there's no drift, marking the spec in git as the authoritative one. Once everything's building happily in Koji its repos could become the authorative ones. Crazy talk? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
This all sounds exciting, but since Devrim is out, let's table the discussion till he gets back (or at least gets near akeyboard). On Aug 19, 2014, at 1:45 AM, Craig Ringer <craig@2ndQuadrant.com> wrote: > Hi all > > I'm interested in getting more involved in the RPM packaging process for > PostgreSQL. I know I'm new to the scene, so the following might be > jumping the gun a bit, but I'm also aware that it's hard to find time > for PGDG RPM work and more contribution might be valued. > > I've produced new spec files for PostgreSQL 9.4 that unify all of > EL-5/6/7 and Fedora 19/20/21 into a single spec that can be rebuilt for > each platform, and I think that's ready for wider testing now. Builds > for all platforms work correctly using 'mock' on a Fedora 20 build-host, > and they test-install into the target platform correctly, and > interoperate with existing PGDG RPMs. > > I've fixed a number of packaging bugs in the process. I'll attach the > spec and the rest of the RPM sources in a followup mail to the "unifying > the spec files" thread. > > I'm looking at future steps now, and I'd like to outline some ideas that > might make PGDG RPMs easier to maintain, more friendly toward > contribution from others, more reliable, easier to test, and more > inter-operable with other repositories. > > My personal motivation - just so I'm upfront about this - is that what > I'm talking about would make it a *lot* easier for me to produce > "hotfix" RPMs for 2ndQuadrant customers who want fixes backported before > a new minor release, produce backport RPMs where they want something > backported into 9.2 or whatever, produce RPMs for customers with > perf/bug fixes that haven't been accepted by upstream yet, and make > packaging BDR a lot easier too. > > From my understanding of how things currently work I think it'd also > make it easier to maintain PGDG, but of course I don't have much history > here or the experience with the current process to really back that. > > > I'd like to (short version): > > * Depend on EPEL > (some packages already do, it's just not declared) > * Drop packages from PGDG that're already in EPEL > * Unify spec files for different dists > * Build with Mock > * Use Koji > * Test with Mock > * Let Koji handle createrepo etc > * Move package management to git > > > Details of what I'm suggesting: > > - Depend on EPEL for RHEL/CentOS/SciLinux and remove all packages > provided by EPEL from PGDG to reduce duplication and potential for > conflicts. (This might involve applying for EPEL dev status > eventually, but shouldn't to start with). > > As many packages would work w/o EPEL I doubt it'd have to be a hard > dependency. Just say that EPEL is recommended and will be required > for some packages. > > > - Progressively unify spec files for other packages to remove the need > for individual specs for each target OS, like I've already done > for postgresql94. (Done for Pg 9.4, not prior, but see next item). > > > - For PostgreSQL packages also make the major versions supported in the > same define, just by changing the macros. So packaging bug fixes are > easier. (I haven't done this, but it doesn't look too hard). > > > - Always build packages using mock, so issues with build-depends and > undeclared runtime dependencies like those I've recently reported are > identified at build time. (This works with the packages I've > rewritten). > > Use mock target definition files that include EPEL repositories for > EL targets. > > > - Test-install packages in another mock chroot after building, and > run some basic tests - initdb, etc, at least. Trivial to automate, > just run a script within the mock chroot. (I've done part of this > and it's not hard to finish off). > > > - Automate package building with mock via Koji by setting up a Koji > server for PGDG. This is fairly well documented, and really just > needs a host with a pile of disk space, preferably running a new > Fedora release. Builds can then be submitted to Koji, either as SRPMs > or via pushes to git. The latter involves tarballs in git, but > that's what Fedora does. > > Koji can pull the packages from Fedora and EPEL to use as a base > for builds, but (using Mock) will only install and enable those > declared for dependencies or build-depends in any individual build. > > I haven't set a Koji up, but I'd very much like to. If PGDG > wants to go this way I'll be happy to do it for PGDG, rather than > creating a private Koji. > > Check out: > > http://koji.fedoraproject.org/koji/ > https://fedorahosted.org/koji/ > > 'mash' is used to manage koji -> yum repo work. > > > - Let Koji take care of running createrepo, repoview, etc as updates > are pushed, rather than running the manually; > > > - Test repositories with repoclosure and complain if we find > dependencies that can't be satisfied, e.g. > > repoclosure -l fedora -l pgdg94 > > or > > repoclosure -l el5 -l epel5 -l pgdg91 > > (with a corresponding yum configuration). > > This can be done within 'mock', or with individual yum config files > rather than using the system ones. > > > > Thoughts? > > It probably makes sense to fire up a Koji instance first. Then start > progressively getting packages building with corrected build-depends and > depends, using mock, and where possible unified to build the same spec > on all dists, moving them into Koji-friendly git management as that happens. > > As packages are updated, the copy in svn would want to be updated to > match so there's no drift, marking the spec in git as the authoritative one. > > Once everything's building happily in Koji its repos could become the > authorative ones. > > Crazy talk? > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > > -- > Sent via pgsql-pkg-yum mailing list (pgsql-pkg-yum@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-pkg-yum --- Jeff Frost <jeff@pgexperts.com> CTO, PostgreSQL Experts, Inc. Phone: 1-888-PG-EXPRT x506 FAX: 415-762-5122 http://www.pgexperts.com/
On 08/20/2014 02:01 AM, Jeff Frost wrote: > This all sounds exciting, but since Devrim is out, let's table the discussion till he gets back (or at least gets neara keyboard). Sensible. BTW, I've been doing some verification of the PGDG repos with repocirc after having a series of problems getting things to install. It's spotting a fair few new issues, as well as those I've already raised in http://www.postgresql.org/message-id/53EC38F5.9080500@2ndquadrant.com and http://www.postgresql.org/message-id/53F37253.4000706@2ndquadrant.com . For example, 9.3 on RHEL5: sudo repoclosure -n -c /tmp/yum.conf -r pgdg93 -l core -l update -l extras with the attached yum.conf, where it's checking pgdg93 against RHEL core and updates plus EPEL, reports quite a bit of breakage (my comments inline): package: ora2pg-12.0-1.rhel5.noarch from pgdg93 unresolved deps: perl(DBD::Oracle) package: pg_activity-0.2.0-1.rhel5.noarch from pgdg93 unresolved deps: python > 0:2.6 python-psycopg2 > 0:2.2.1 python-psutil > 0:0.5.1 package: pg_comparator93-2.2.2-1.rhel5.x86_64 from pgdg93 unresolved deps: perl-Pod-Usage package: pgdg-sl93-9.3-1.noarch from pgdg93 unresolved deps: sl-release package: pgtap93-0.94.0-1.rhel5.noarch from pgdg93 unresolved deps: perl-Test-Harness >= 0:3.0 package: usda-r18-1.0-2.rhel5.noarch from pgdg93 unresolved deps: postgresql91 There's a packaging bug in usda, pg_activity depends on Python > 2.6 (on RHEL5?!?) and there are a bunch of unsatisfied module dependencies that need fixing, or documenting to explain where to get them from. Now if I remove EPEL (which PGDG doesn't officially depend on), I get a *lot* more issues. (I've removed entries already fully covered above, these are just the new EPEL dependencies): package: ora2pg-12.0-1.rhel5.noarch from pgdg93 unresolved deps: perl(DBD::Oracle) # covered above perl(IO::Compress::Base) perl(String::Random) package: pg_partman93-1.7.0-1.rhel5.x86_64 from pgdg93 unresolved deps: python-psycopg2 package: pgadmin3_93-1.18.0-1.rhel5.i386 from pgdg93 unresolved deps: libwx_gtk2u_xrc-2.8.so.0(WXU_2.8) libwx_gtk2u_core-2.8.so.0(WXU_2.8) libwx_baseu-2.8.so.0(WXU_2.8.5) libwx_gtk2u_aui-2.8.so.0(WXU_2.8) libwx_gtk2u_adv-2.8.so.0(WXU_2.8) libwx_gtk2u_stc-2.8.so.0 libwx_gtk2u_xrc-2.8.so.0 libwx_gtk2u_adv-2.8.so.0 libwx_gtk2u_core-2.8.so.0 libwx_gtk2u_aui-2.8.so.0 libwx_baseu_net-2.8.so.0(WXU_2.8) libwx_gtk2u_html-2.8.so.0(WXU_2.8) wxGTK libwx_baseu-2.8.so.0 libwx_baseu_xml-2.8.so.0 libwx_baseu_xml-2.8.so.0(WXU_2.8) libwx_gtk2u_stc-2.8.so.0(WXU_2.8) libwx_gtk2u_html-2.8.so.0 libwx_gtk2u_aui-2.8.so.0(WXU_2.8.5) libwx_baseu_net-2.8.so.0 libwx_baseu-2.8.so.0(WXU_2.8) package: pgloader-2.3.2-1.rhel5.x86_64 from pgdg93 unresolved deps: python-psycopg2 package: pgpool-II-93-3.3.2-1.rhel5.x86_64 from pgdg93 unresolved deps: libmemcached.so.2()(64bit) libmemcached.so.2(libmemcached_2)(64bit) package: plr93-8.3.0.15-1.rhel5.x86_64 from pgdg93 unresolved deps: libR.so()(64bit) package: postgis2_93-2.1.3-1.rhel5.x86_64 from pgdg93 unresolved deps: json-c hdf5 libjson.so.0()(64bit) package: postgresql93-contrib-9.3.5-1PGDG.rhel5.x86_64 from pgdg93 unresolved deps: libossp-uuid.so.15()(64bit) package: postgresql_autodoc-1.41-1.rhel5.noarch from pgdg93 unresolved deps: perl(HTML::Template) perl-TermReadKey perl(Term::ReadKey) package: skytools-93-3.1.5-1.rhel5.x86_64 from pgdg93 unresolved deps: python-psycopg2 so I think PGDG already depends on EPEL. It just doesn't declare it, do so systematically, or manage those dependencies. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Attachment
On 08/20/2014 02:01 AM, Jeff Frost wrote: > This all sounds exciting, but since Devrim is out, let's table the discussion till he gets back (or at least gets neara keyboard). Devrim, any thoughts re the following? I'm particularly interested in adopting a unified specfile for the postgresql package (for starters), then adopting mock for builds. With Koji and packages in git to follow. > On Aug 19, 2014, at 1:45 AM, Craig Ringer <craig@2ndQuadrant.com> wrote: > >> Hi all >> >> I'm interested in getting more involved in the RPM packaging process for >> PostgreSQL. I know I'm new to the scene, so the following might be >> jumping the gun a bit, but I'm also aware that it's hard to find time >> for PGDG RPM work and more contribution might be valued. >> >> I've produced new spec files for PostgreSQL 9.4 that unify all of >> EL-5/6/7 and Fedora 19/20/21 into a single spec that can be rebuilt for >> each platform, and I think that's ready for wider testing now. Builds >> for all platforms work correctly using 'mock' on a Fedora 20 build-host, >> and they test-install into the target platform correctly, and >> interoperate with existing PGDG RPMs. >> >> I've fixed a number of packaging bugs in the process. I'll attach the >> spec and the rest of the RPM sources in a followup mail to the "unifying >> the spec files" thread. >> >> I'm looking at future steps now, and I'd like to outline some ideas that >> might make PGDG RPMs easier to maintain, more friendly toward >> contribution from others, more reliable, easier to test, and more >> inter-operable with other repositories. >> >> My personal motivation - just so I'm upfront about this - is that what >> I'm talking about would make it a *lot* easier for me to produce >> "hotfix" RPMs for 2ndQuadrant customers who want fixes backported before >> a new minor release, produce backport RPMs where they want something >> backported into 9.2 or whatever, produce RPMs for customers with >> perf/bug fixes that haven't been accepted by upstream yet, and make >> packaging BDR a lot easier too. >> >> From my understanding of how things currently work I think it'd also >> make it easier to maintain PGDG, but of course I don't have much history >> here or the experience with the current process to really back that. >> >> >> I'd like to (short version): >> >> * Depend on EPEL >> (some packages already do, it's just not declared) >> * Drop packages from PGDG that're already in EPEL >> * Unify spec files for different dists >> * Build with Mock >> * Use Koji >> * Test with Mock >> * Let Koji handle createrepo etc >> * Move package management to git >> >> >> Details of what I'm suggesting: >> >> - Depend on EPEL for RHEL/CentOS/SciLinux and remove all packages >> provided by EPEL from PGDG to reduce duplication and potential for >> conflicts. (This might involve applying for EPEL dev status >> eventually, but shouldn't to start with). >> >> As many packages would work w/o EPEL I doubt it'd have to be a hard >> dependency. Just say that EPEL is recommended and will be required >> for some packages. >> >> >> - Progressively unify spec files for other packages to remove the need >> for individual specs for each target OS, like I've already done >> for postgresql94. (Done for Pg 9.4, not prior, but see next item). >> >> >> - For PostgreSQL packages also make the major versions supported in the >> same define, just by changing the macros. So packaging bug fixes are >> easier. (I haven't done this, but it doesn't look too hard). >> >> >> - Always build packages using mock, so issues with build-depends and >> undeclared runtime dependencies like those I've recently reported are >> identified at build time. (This works with the packages I've >> rewritten). >> >> Use mock target definition files that include EPEL repositories for >> EL targets. >> >> >> - Test-install packages in another mock chroot after building, and >> run some basic tests - initdb, etc, at least. Trivial to automate, >> just run a script within the mock chroot. (I've done part of this >> and it's not hard to finish off). >> >> >> - Automate package building with mock via Koji by setting up a Koji >> server for PGDG. This is fairly well documented, and really just >> needs a host with a pile of disk space, preferably running a new >> Fedora release. Builds can then be submitted to Koji, either as SRPMs >> or via pushes to git. The latter involves tarballs in git, but >> that's what Fedora does. >> >> Koji can pull the packages from Fedora and EPEL to use as a base >> for builds, but (using Mock) will only install and enable those >> declared for dependencies or build-depends in any individual build. >> >> I haven't set a Koji up, but I'd very much like to. If PGDG >> wants to go this way I'll be happy to do it for PGDG, rather than >> creating a private Koji. >> >> Check out: >> >> http://koji.fedoraproject.org/koji/ >> https://fedorahosted.org/koji/ >> >> 'mash' is used to manage koji -> yum repo work. >> >> >> - Let Koji take care of running createrepo, repoview, etc as updates >> are pushed, rather than running the manually; >> >> >> - Test repositories with repoclosure and complain if we find >> dependencies that can't be satisfied, e.g. >> >> repoclosure -l fedora -l pgdg94 >> >> or >> >> repoclosure -l el5 -l epel5 -l pgdg91 >> >> (with a corresponding yum configuration). >> >> This can be done within 'mock', or with individual yum config files >> rather than using the system ones. >> >> >> >> Thoughts? >> >> It probably makes sense to fire up a Koji instance first. Then start >> progressively getting packages building with corrected build-depends and >> depends, using mock, and where possible unified to build the same spec >> on all dists, moving them into Koji-friendly git management as that happens. >> >> As packages are updated, the copy in svn would want to be updated to >> match so there's no drift, marking the spec in git as the authoritative one. >> >> Once everything's building happily in Koji its repos could become the >> authorative ones. >> >> Crazy talk? >> -- >> Craig Ringer http://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Training & Services >> >> >> -- >> Sent via pgsql-pkg-yum mailing list (pgsql-pkg-yum@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-pkg-yum > > --- > Jeff Frost <jeff@pgexperts.com> > CTO, PostgreSQL Experts, Inc. > Phone: 1-888-PG-EXPRT x506 > FAX: 415-762-5122 > http://www.pgexperts.com/ > > > > > -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services