On Thu, Aug 11, 2005 at 09:31:11AM +0200, Martin Pitt wrote: > Steve Langasek [2005-08-08 17:11 -0700]: > > I've been taking a closer look at the new postgresql -dev package layout > > now that FTBFS bugs are finding themselves filed against packages, and > > I'm concerned that the current layout seems to more or less gratuitously > > break compatibility with historical sources.
> This was done with the possibility in mind to allow installation of > several versions of libpq-dev in mind. E. g. suppose postgresql-8.1 > introduces a new client API libpq5, so we need libpq4-dev and > libpq5-dev. Since we also want to support older major releases of > postgresql, we can't just drop libpq4-dev. That, and the existence of > pg_config (which should be used by packages to solve this problem once > and for all) were the reasons why I did it that way. So does this mean you foresee a future version of libpq (libpq5) which not only breaks the ABI and the API, but also is incompatible at the protocol level with older pgsql servers? If not, I really can't see a reason to support two simultaneous -dev packages except on a purely transitional basis. Even for an API change, there are only 30 or so reverse-depends of libpq4 in etch right now, so I think if the API change is even remotely sane in scope it would be better to push the change through within a single release cycle. > > The package moves the headers from /usr/include/postgresql/ to > > /usr/include/postgresql/8.0/, which definitely breaks any sources that > > include the headers as <postgresql/foo.h>; and the recommended interface > > for detecting the include path is now pg_config --includedir. > > But there can only ever be one package installed at a time which > > provides pg_config... So if all such -dev packages must conflict, why > > not use the /usr/include/postgresql/ path directly? > Right, this is not yet perfect yet. It is possible to change pg_config > to work for multiple libpqX-dev, it just didn't happen yet since it is > not necessary right now. Ok. I guess you've at least thought about this issue more than I have, since I can't really see a way that pg_config could be usefully changed to do this. :) > > I realize this may be the result of an upstream decision, but I think > > this is worth considering given the number of packages that are still > > failing to build as a result of this change. > I see your point. I'm just afraid that this takes the pressure out of > maintainers to drop the postgresql-dev dependency out of their > packages and use pg_config to get the path information. I definitively > want to drop postgresql-dev after Etch, so at some point maintainers > just _have_ to fix their packages. But if it helps the release > process, I can certainly move the client-side include files back to > the old location. Yeah, this is just the difference between forcing maintainers to fix their packages immediately because they have RC bugs, and fixing them sometime between now and the etch release because there's a new recommended build-dependency. But when the include path change inspires people to file bug reports with such suggestions as #include <postgresql/8.0/libpq-fe.h>, it seems to me it would be better to leave the header path alone and just drop postgresql-dev instead :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
