| 1 |
* Tiziano Müller <dev-zero@g.o> schrieb: |
| 2 |
|
| 3 |
Hi, |
| 4 |
|
| 5 |
> Since my blog doesn't get syndicated on planet.gentoo.org I'm posting the |
| 6 |
> entry here again, but it's probably a good idea anyway: |
| 7 |
|
| 8 |
Actually, I'd clearly prefer lists like this one for those discussions. |
| 9 |
Blogs are okay for writing journal articles and let people comment them, |
| 10 |
but bad for real discussions, IMHO. |
| 11 |
|
| 12 |
> First I want to apologize for the current situation. I know we're lagging |
| 13 |
> behind and I know that bugs are piling up. |
| 14 |
> As a small excuse I can only say that my time is limited and PostgreSQL |
| 15 |
> isn't the only thing in Gentoo I (have to) maintain. |
| 16 |
|
| 17 |
Well, my time is limited too (hmm, an contract for Gentoo development |
| 18 |
would be fine ;-)), otherwise I'd already reworked the pg ebuilds ;-o |
| 19 |
|
| 20 |
> There are a couple of reasons: |
| 21 |
> a) dev-db/libpq is slotted but with collisions. Fixing this wasn't really an |
| 22 |
> option since slotting this was wrong from the beginning. |
| 23 |
|
| 24 |
ACK. It should be done by *real* MVCC. But I doubt that portage is |
| 25 |
actually capable of this yet. For the vast majority of the cases I |
| 26 |
see slots just as a dirty hack ;-p |
| 27 |
|
| 28 |
The main problem for MVCC (and also what often makes revdep-rebuild |
| 29 |
necessary) is the point that source and binary packages have to be |
| 30 |
completely different: the mapping from source to binary happens at |
| 31 |
only build time and all the rest of the dependency handling derives |
| 32 |
from that. I'm currently implementing this approach in my own build/ |
| 33 |
packaging system, but it's going to tricky. |
| 34 |
|
| 35 |
> b) The split-up in two packages dev-db/{libpq,postgresql} was wrong too: |
| 36 |
> There are a couple of packages which do not only need libpq, but also one |
| 37 |
> of the other PostgreSQL libraries (like libecpg, libpgtypes, libecpg_compat |
| 38 |
> or libpgport). |
| 39 |
|
| 40 |
NAK! Each of these libraries are their own entities. Some clients even may |
| 41 |
depend on one of them, but not libpq. So they clearly belong to their |
| 42 |
own packages. |
| 43 |
|
| 44 |
I do *NOT* want *ANY* unneeded stuff in my systems. You'll force me to fork. |
| 45 |
|
| 46 |
> c) Upgrading between major versions of PostgreSQL requires the DB admin to |
| 47 |
> bump the database using the old version, moving the database away and to |
| 48 |
> reload the dump into a new database cluster using the new version of |
| 49 |
> PostgreSQL. Having to take down the old server and purging the old version |
| 50 |
> of PostgreSQL before being able to try out the new one is more than |
| 51 |
> cumbersome. Therefore a slotted postgresql-server is needed to make the |
| 52 |
> upgrade easier. |
| 53 |
|
| 54 |
That's the point where we need *real* MVCC. An virtual package could |
| 55 |
coordinate the update process (eg. pulling in new versions and providing |
| 56 |
update utils, maybe with some additional refcounting and automatic cleanup |
| 57 |
based on that) |
| 58 |
|
| 59 |
Yes, MVCC is not trivial ;-P |
| 60 |
|
| 61 |
> What do the new ebuilds offer: |
| 62 |
> a) A split into dev-db/postgresql-{base,server,docs}. Now, I know that |
| 63 |
> splitting up packages isn't the Gentoo way. I know we could have done it |
| 64 |
> using USE flags but this approach gives more flexibility due to the current |
| 65 |
> way how binary packages are being generated and distributed. |
| 66 |
|
| 67 |
I actually think packages should be split whenever suitable, useflags should |
| 68 |
only be used for *conditional* building (where features are switched that |
| 69 |
do *not* reflect separate modules) or for virtual (frontend) packages. |
| 70 |
|
| 71 |
> b) New virtuals: virtual/postgresql-{base,server} to be able to install |
| 72 |
> pgcluster as your postgresql-base in a next step. |
| 73 |
|
| 74 |
Yes, frontend virtuals for convenience are an good idea for many users. |
| 75 |
I, personally, probably won't use them, since my setups would be too |
| 76 |
complex for them. Other folks with simpler setups might be perfectly |
| 77 |
fine with them. |
| 78 |
|
| 79 |
> c) Slotting: It is now possible to have more than one major version of |
| 80 |
> PostgreSQL installed and running on the same machine. |
| 81 |
|
| 82 |
Great. This makes smooth update processes easier (reduces the need of |
| 83 |
custom ebuilds). But I, pesonally, prefer *separate* packages instead |
| 84 |
of slots. |
| 85 |
|
| 86 |
> 159223 postgresql threads USE flag required for ecpg |
| 87 |
|
| 88 |
BTW: does portage meanwhile handle feature dependencies ? |
| 89 |
It's always a big mess when an whole install/update fails in the middle |
| 90 |
just because some package wants some other built with certain useflag :( |
| 91 |
|
| 92 |
> 161980 QA Notice: USE Flag 'kernel_linux' not in IUSE for dev-db... |
| 93 |
|
| 94 |
Naive question: why does this useflag appear in pg ? |
| 95 |
|
| 96 |
|
| 97 |
cu |
| 98 |
-- |
| 99 |
--------------------------------------------------------------------- |
| 100 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
| 101 |
--------------------------------------------------------------------- |
| 102 |
Please visit the OpenSource QM Taskforce: |
| 103 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
| 104 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
| 105 |
http://patches.metux.de/ |
| 106 |
--------------------------------------------------------------------- |
| 107 |
-- |
| 108 |
gentoo-dev@l.g.o mailing list |
Archives