From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JmX12-0000bk-WB for garchives@archives.gentoo.org; Thu, 17 Apr 2008 16:31:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4B4B7E059F; Thu, 17 Apr 2008 16:31:15 +0000 (UTC) Received: from s15216962.onlinehome-server.info (s15216962.onlinehome-server.info [217.160.22.205]) by pigeon.gentoo.org (Postfix) with ESMTP id 106DCE059F for ; Thu, 17 Apr 2008 16:31:14 +0000 (UTC) Received: (from uucp@localhost) by s15216962.onlinehome-server.info (8.13.3/8.13.3) with UUCP id m3HGVEJt011342 for gentoo-dev@lists.gentoo.org; Thu, 17 Apr 2008 18:31:14 +0200 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id m3HGUiNm005248 for gentoo-dev@lists.gentoo.org; Thu, 17 Apr 2008 18:30:44 +0200 Date: Thu, 17 Apr 2008 18:30:44 +0200 From: Enrico Weigelt To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] PostgreSQL Status Message-ID: <20080417163044.GA31409@nibiru.local> References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.1i X-Terror: bin laden, kill bush, Briefbombe, Massenvernichtung, KZ, X-Nazi: Weisse Rasse, Hitlers Wiederauferstehung, 42, X-Antichrist: weg mit schaeuble, ausrotten, heiliger krieg, al quaida, X-Killer: 23, endloesung, Weltuntergang, X-Doof: wer das liest ist doof X-Archives-Salt: 8bfd5e52-f76d-4ac8-ad5f-371b165db725 X-Archives-Hash: 9b7d21b602e2906f85a5d3aa8d599e08 * Tiziano M=FCller 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=20 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=20 actually capable of this yet. For the vast majority of the cases I=20 see slots just as a dirty hack ;-p The main problem for MVCC (and also what often makes revdep-rebuild=20 necessary) is the point that source and binary packages have to be=20 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_comp= at > 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=20 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 curre= nt > way how binary packages are being generated and distributed. I actually think packages should be split whenever suitable, useflags shoul= d=20 only be used for *conditional* building (where features are switched that= =20 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=20 complex for them. Other folks with simpler setups might be perfectly=20 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=20 custom ebuilds). But I, pesonally, prefer *separate* packages instead=20 of slots.=20 > 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 --=20 --------------------------------------------------------------------- Enrico Weigelt =3D=3D 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