* Tiziano Müller <[EMAIL PROTECTED]> schrieb:
Hi,
> 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:
Actually, I'd clearly prefer lists like this one for those discussions.
Blogs are okay for writing journal articles and let people comment them,
but bad for real discussions, IMHO.
> 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.
Well, my time is limited too (hmm, an contract for Gentoo development
would be fine ;-)), otherwise I'd already reworked the pg ebuilds ;-o
> 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.
ACK. It should be done by *real* MVCC. But I doubt that portage is
actually capable of this yet. For the vast majority of the cases I
see slots just as a dirty hack ;-p
The main problem for MVCC (and also what often makes revdep-rebuild
necessary) is the point that source and binary packages have to be
completely different: the mapping from source to binary happens at
only build time and all the rest of the dependency handling derives
from that. I'm currently implementing this approach in my own build/
packaging system, but it's going to tricky.
> 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).
NAK! Each of these libraries are their own entities. Some clients even may
depend on one of them, but not libpq. So they clearly belong to their
own packages.
I do *NOT* want *ANY* unneeded stuff in my systems. You'll force me to fork.
> 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.
That's the point where we need *real* MVCC. An virtual package could
coordinate the update process (eg. pulling in new versions and providing
update utils, maybe with some additional refcounting and automatic cleanup
based on that)
Yes, MVCC is not trivial ;-P
> 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.
I actually think packages should be split whenever suitable, useflags should
only be used for *conditional* building (where features are switched that
do *not* reflect separate modules) or for virtual (frontend) packages.
> b) New virtuals: virtual/postgresql-{base,server} to be able to install
> pgcluster as your postgresql-base in a next step.
Yes, frontend virtuals for convenience are an good idea for many users.
I, personally, probably won't use them, since my setups would be too
complex for them. Other folks with simpler setups might be perfectly
fine with them.
> c) Slotting: It is now possible to have more than one major version of
> PostgreSQL installed and running on the same machine.
Great. This makes smooth update processes easier (reduces the need of
custom ebuilds). But I, pesonally, prefer *separate* packages instead
of slots.
> 159223 postgresql threads USE flag required for ecpg
BTW: does portage meanwhile handle feature dependencies ?
It's always a big mess when an whole install/update fails in the middle
just because some package wants some other built with certain useflag :(
> 161980 QA Notice: USE Flag 'kernel_linux' not in IUSE for dev-db...
Naive question: why does this useflag appear in pg ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
--
gentoo-dev@lists.gentoo.org mailing list
