* Tiziano Mueller <[EMAIL PROTECTED]> schrieb: Hi,
> >since jakub (as always) closes all my bugs, I'll report the issue > >to this list before completely giving up and never ever waste a > >single second on reporting bugs ... > ... and we're grateful to you for that. For reporting this issue or for not reporting anythin in future ? > >Lots of packages have an wrong/unnecessary dependency to > >postgresql. Three cases: > Two. ( a) + b) '=' two cases ) ugh, I first wanted to write about three ones, but while writing this mail I've seen they're actually two, while some packages have both ... ;-o > >a) probably traditionally depended on the whole postgresql, maybe > > since before libpq was an own package. ie. qt, dovecot, ... > No. At least that's not the only reason. Which other reasons do we have ? > Since you reported a duplicated bug-report (bug #158978) for the issue I'm > talking about, I thought you would have noted. Aehm, completely different front. Right, I should have find the dup by myself, but I was quite in a hurry at this time. The alternative would have been not telling anything about any problems I've found. > But let's make it clear: > There is this pg_config app which can be used by other apps to get > includedir/libdir/cflags/ldflags/etc for the postgresql-libraries. > This app has been installed by dev-db/postgresql until the latest > minor version bumps (7.3.16, 7.4.14, 8.0.9-r1, 8.1.5-r1) for which > we have an open stabilization bug (bug #152783). In other words: the splitoff between postgresql and libpg has been buggy in some (older) versions, which are still in use / necessary ? So certain packages importing libpq may require postgresql if libpq's version is too old. I currently see two ways out of this: a) Fix the older libpq versions too. If it's just the missing pg_config, it should be just a few lines to add. b) use multiple-choice-dependencies (||): if libpq is new enough, import it, otherwise import postgresql. I'd prefer the a) and so attached an fixed ebuild for 8.0.8. The change is quite minor, so stableizing should go quite quick here. > Until this bug is closed, stable packages which try to depend only > on libpq instead of postgresql will eventually get an older version > (depending on the arch) and fail. Therefore those bugs are invalid. Ah, and they become valid as soon as the pg_config issue is cleared ? <snip> > >b) many apps (ie. webapps like bugzilla) have postgresql as dep., > > although they do not need it to be installed. (ie. bugzilla does > > not have to do anything directly w/ postgresql, since it uses > > perl-DBD for database access). Of course they maybe want to > > have access to some postgres database, but this obviously does > > not need an local server. > Thanks a lot for pointing this out. But be assured that we already > know about the issue and we will solve it as soon as the mentioned > versions of postgresql are stable on all archs together with the > other dependencies. IMHO, the bugzilla bug could be fixed now, since it's dependency is not necessary at all - or does bugzilla use pg_config ? > And we really don't need help to identify the packages in question, > nor a bug-report for every single one of them, but thanks again. Well, my intention simply was: one bug per job/issue, and each package by it's own. Assuming packages have different maintainers and aren't fixed all at the same time ... > Thanks for reporting the issues and the interest in our work. BTW: the first time I'm reading such words on this list :) 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/ --------------------------------------------------------------------- -- [email protected] mailing list
