Since my blog doesn't get syndicated on planet.gentoo.org I'm posting the
entry here again, but it's probably a good idea anyway:
First I want to apologize for the current situation. I know we're lagging
behind and I know that bugs are piling up.
As a small excuse I can only say that my time is limited and PostgreSQL
isn't the only thing in Gentoo I (have to) maintain.
But there are good news:
Thanks to the help of Michael Krelin (also known as polyonymous on IRC) I
was able to commit a whole new set of ebuilds yesterday.
Now, you're probably going to ask why we just didn't go on with the current
ebuilds in the tree.
There are a couple of reasons:
a) dev-db/libpq is slotted but with collisions. Fixing this wasn't really an
option since slotting this was wrong from the beginning.
b) The split-up in two packages dev-db/{libpq,postgresql} was wrong too:
There are a couple of packages which do not only need libpq, but also one
of the other PostgreSQL libraries (like libecpg, libpgtypes, libecpg_compat
or libpgport).
c) Upgrading between major versions of PostgreSQL requires the DB admin to
bump the database using the old version, moving the database away and to
reload the dump into a new database cluster using the new version of
PostgreSQL. Having to take down the old server and purging the old version
of PostgreSQL before being able to try out the new one is more than
cumbersome. Therefore a slotted postgresql-server is needed to make the
upgrade easier.
d) A lot of things were broken in the old postgresql ebuilds as you can see
when going through the bug list and we needed to give them a general
overhaul.
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}. Now, I know that
splitting up packages isn't the Gentoo way. I know we could have done it
using USE flags but this approach gives more flexibility due to the current
way how binary packages are being generated and distributed.
b) New virtuals: virtual/postgresql-{base,server} to be able to install
pgcluster as your postgresql-base in a next step.
c) Slotting: It is now possible to have more than one major version of
PostgreSQL installed and running on the same machine.
d) A lot of other improvements, in detail, the following bugs will be fixed:
42894 Suggestion of use of slots for PostgreSQL
49864 dev-db/postgresql - pkg_config should allow passing optio...
55073 PostgreSQL client versus server installation
154620 PostgreSQL 8.1 server lacks instrumentation functions for...
158509 dev-db/libpq-8.0.9 fails configure with segmentation faul...
159223 postgresql threads USE flag required for ecpg
160178 dev-db/libpq : using (almost deprecated) gnuconfig_update
160181 dev-db/postgresql : using (almost deprecated) gnuconfig_u...
161803 dev-db/postgresql - /etc/conf.d/postgresql PG_OPTS variab...
161980 QA Notice: USE Flag 'kernel_linux' not in IUSE for dev-db...
177555 Postgresql/libpg upgrade from 8.1.8 to libpg-8.2.4 and po...
194350 >=dev-db/libpq-8.2.4 creates broken symlinks
194701 dev-db/postgresql - wrong elog into about configuration f...
198434 dev-db/postgresql - add ldap use flag
206725 dev-db/{libpq,postgresql} 8.2.7/8.3.1 version bump
206820 dev-db/postgresql default conf.d should not override max_...
209826 dev-db/postgresql - 2 issues with the current init script
210938 dev-db/postgresql - disable strict permission check on ss...
213699 dev-db/libpq-8.2.6 failed to configure w/ USE="threads"
214438 The dev-db/postgresql-8.2.6 ebuild does not respect confi...
215940 dev-db/postgresql provides bad init script for baselayout...
What you have to do to switch:
I'll put together more documentation as soon as the ebuilds get unmasked (in
1-2 weeks).
In general the only thing you have to then do is to uninstall dev-db/libpq
and dev-db/postgresql and install the same version of postgresql-base and
postgresql-server. No revdep-rebuild is needed.
For early adopters: It's best to wait until we changed the dependencies,
afterwards you can unmask the dev-db/postgresql-{docs,base,server}
packages...
What is needed from the ebuild developers side:
We have to change every dependency on dev-db/libpq to
virtual/postgresql-base and dev-db/postgresql to virtual/postgresql-server.
As soon as the old ebuilds are gone, we have to go through the ebuilds
depending on virtual/postgresql-server whether they can be built with
dev-db/postgresql-base only. Do not switch from dev-db/postgresql to
virtual/postgresql-base directly as long as you can't assure that your
package builds with libpq only.
Well, that's it basically. Don't hesitate to contact me in case of problems
or suggestions. You can answer to this post, leave comments on
http://dev-zero.ch/blog/ or send me a mail of course :-).
(But don't expect me to read forum entries since I simply do not have the
time to do that regularly.)
Again, many thanks to Michael Krelin and all the others who helped with
testing and sending patches.
Cheers,
Tiziano
--
gentoo-dev@lists.gentoo.org mailing list
entry here again, but it's probably a good idea anyway:
First I want to apologize for the current situation. I know we're lagging
behind and I know that bugs are piling up.
As a small excuse I can only say that my time is limited and PostgreSQL
isn't the only thing in Gentoo I (have to) maintain.
But there are good news:
Thanks to the help of Michael Krelin (also known as polyonymous on IRC) I
was able to commit a whole new set of ebuilds yesterday.
Now, you're probably going to ask why we just didn't go on with the current
ebuilds in the tree.
There are a couple of reasons:
a) dev-db/libpq is slotted but with collisions. Fixing this wasn't really an
option since slotting this was wrong from the beginning.
b) The split-up in two packages dev-db/{libpq,postgresql} was wrong too:
There are a couple of packages which do not only need libpq, but also one
of the other PostgreSQL libraries (like libecpg, libpgtypes, libecpg_compat
or libpgport).
c) Upgrading between major versions of PostgreSQL requires the DB admin to
bump the database using the old version, moving the database away and to
reload the dump into a new database cluster using the new version of
PostgreSQL. Having to take down the old server and purging the old version
of PostgreSQL before being able to try out the new one is more than
cumbersome. Therefore a slotted postgresql-server is needed to make the
upgrade easier.
d) A lot of things were broken in the old postgresql ebuilds as you can see
when going through the bug list and we needed to give them a general
overhaul.
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}. Now, I know that
splitting up packages isn't the Gentoo way. I know we could have done it
using USE flags but this approach gives more flexibility due to the current
way how binary packages are being generated and distributed.
b) New virtuals: virtual/postgresql-{base,server} to be able to install
pgcluster as your postgresql-base in a next step.
c) Slotting: It is now possible to have more than one major version of
PostgreSQL installed and running on the same machine.
d) A lot of other improvements, in detail, the following bugs will be fixed:
42894 Suggestion of use of slots for PostgreSQL
49864 dev-db/postgresql - pkg_config should allow passing optio...
55073 PostgreSQL client versus server installation
154620 PostgreSQL 8.1 server lacks instrumentation functions for...
158509 dev-db/libpq-8.0.9 fails configure with segmentation faul...
159223 postgresql threads USE flag required for ecpg
160178 dev-db/libpq : using (almost deprecated) gnuconfig_update
160181 dev-db/postgresql : using (almost deprecated) gnuconfig_u...
161803 dev-db/postgresql - /etc/conf.d/postgresql PG_OPTS variab...
161980 QA Notice: USE Flag 'kernel_linux' not in IUSE for dev-db...
177555 Postgresql/libpg upgrade from 8.1.8 to libpg-8.2.4 and po...
194350 >=dev-db/libpq-8.2.4 creates broken symlinks
194701 dev-db/postgresql - wrong elog into about configuration f...
198434 dev-db/postgresql - add ldap use flag
206725 dev-db/{libpq,postgresql} 8.2.7/8.3.1 version bump
206820 dev-db/postgresql default conf.d should not override max_...
209826 dev-db/postgresql - 2 issues with the current init script
210938 dev-db/postgresql - disable strict permission check on ss...
213699 dev-db/libpq-8.2.6 failed to configure w/ USE="threads"
214438 The dev-db/postgresql-8.2.6 ebuild does not respect confi...
215940 dev-db/postgresql provides bad init script for baselayout...
What you have to do to switch:
I'll put together more documentation as soon as the ebuilds get unmasked (in
1-2 weeks).
In general the only thing you have to then do is to uninstall dev-db/libpq
and dev-db/postgresql and install the same version of postgresql-base and
postgresql-server. No revdep-rebuild is needed.
For early adopters: It's best to wait until we changed the dependencies,
afterwards you can unmask the dev-db/postgresql-{docs,base,server}
packages...
What is needed from the ebuild developers side:
We have to change every dependency on dev-db/libpq to
virtual/postgresql-base and dev-db/postgresql to virtual/postgresql-server.
As soon as the old ebuilds are gone, we have to go through the ebuilds
depending on virtual/postgresql-server whether they can be built with
dev-db/postgresql-base only. Do not switch from dev-db/postgresql to
virtual/postgresql-base directly as long as you can't assure that your
package builds with libpq only.
Well, that's it basically. Don't hesitate to contact me in case of problems
or suggestions. You can answer to this post, leave comments on
http://dev-zero.ch/blog/ or send me a mail of course :-).
(But don't expect me to read forum entries since I simply do not have the
time to do that regularly.)
Again, many thanks to Michael Krelin and all the others who helped with
testing and sending patches.
Cheers,
Tiziano
--
gentoo-dev@lists.gentoo.org mailing list
