Re: [gentoo-user] Wrong dependencies to postgresql

[Boyd Stephen Smith Jr.]

On Sunday 24 December 2006 19:37, Enrico Weigelt <weigelt@×××××.de> wrote 
about 'Re: [gentoo-user] Wrong dependencies to postgresql':

First of all, thanks for responding, I was afraid we had lost another savvy 
bugzilla user to the lack of (or discontent with) response from the 
developers.

> * Boyd Stephen Smith Jr. <bss03@××××××××××.net> wrote:
> > Jakub is pretty bugzilla savvy, are you sure you bugs weren't
> > closed for valid reasons?
> well, after some discussion @ gentoo-dev, it's now a little bit
> clearer:

> The bugs are not completely valid yet (but soon will be), since
> libpq (<=8.0.8) is still buggy/incomplete (missing pg_config), so
> some packages may still need postgresql for building (not runtime).
> I supplied fixed ebuild to the -dev, but they told me they don't
> see what I'm fixing ;-o

Heh, like I mentioned/alluded to in my previous posting, once a package it 
working, winnowing down the dependencies is sometimes not seen as 
productive.  I sympathizes with your blight and would volunteer my system 
for chroot building were it not for my lack of time (etc.).

> Well, this issue is actually fixed in 8.0.9 (IMHO not completely
> stabelized yet, but soon), while introducing another, even worse at
> the same time: libpq-8.0.9 doesn't wanna play w/ postgresql<=8.0.8,
> but postgresql-8.0.9 wants exactly libpq-8.0.9. So there's no clean
> way to solve this. Someone @ b.g.o suggested completely removing
> postgres+libpq and installing afresh, but that's an absolutely
> no-go for production systems (IMHO). Disabling deps for upgrade
> should work, but is unclean.

Perhaps a dependency on '|| (>=category/libpq-8.0.9 
<category/postgresql-8.0.9)' would be appropriate in this case.  I believe 
that ordering should prefer the library instead of the whole RDBMS.

In addition, a proper blocker should be added to libpq; I know it doesn't 
help automated upgrades move forward, but at least is stops them from 
blocking issues that *could* be problematic.

> My fixed ebuild should fit into the gap by adding pg_config to
> libpq (overwriting the one from postgresql) and changing the
> postgresql ebuild to be satisfied w/ this libpq version.

Hrm, sounds as if you want a single file to be provided by two packages.  
This is not "the Gentoo way".  In Debian, we have the alternatives 
interface; in gentoo, it's assumed you manage such symlinks with either 
eselect or manually.

If the pg_configs are *different*, you should patch both libpq (to install 
pg_config as pg_config-libpq-$SLOT) and postgresql (to install pg_config 
as pg_config-postgresql-$SLOT) and provide an eslect module to choose the 
appropriate pg_config.

If the pg_configs are *the same*, you should (a) add them to libpq and have 
postgresql depend on libqg--not installing it's own pg_config. or (b) have 
pg_config be it's own package, depended on by both libpq and postgresql.

> > Sometime he does jump the gun though,
>
> Not only at me ? Some bit salving ;-)

Oh yes.  Particularly when marking bugs as duplicates.  There were one or 
two recent out-of-tree kernel module bugs that he marked as duplicates of 
the generic "kernel-2.6.18+ breaks sandbox" bug that weren't actuallt 
duplicates.

That said, Jakub is responsible for 50%+ of the hits to bugs.gentoo.org; he 
*is* for all intents and purposes the bugzilla manager.

Normally, he's correct, but don't worry about respectfully disagreeing with 
him.  He's still human and will make mistakes.

> But I had to learn filing bugs
> and talking @ -dev are just a waste my (rare+expensive) time.

Perhaps your time is more valuable than mine, but I've never found 
reporting bugs to be a waste of time.  Surely, patching the offending 
ebuild/source is better, but such patches should be attached to a bugs for 
the developers/other users to use as well.

> > > Lots of packages have an wrong/unnecessary dependency to
> > > postgresql.
> >
> > I don't doubt it.  It's generally better to depend on too much
> > rather than too little, and once things are "working" it's hard
> > to get someone to "fix" it and run the risk of breaking it further.
>
> Wouldn't be such an problem w/ really cleanroom builds + tests
> from the first place. Seems, Gentoo isn't made for that.

Well, there is a catalyst target for smokescreen/tinderbox building.  I'm 
not sure of the quality but it is supposed to start from a clean image for 
each rebuild, and simply use the binary packages previously built.   I'd 
assume it uses the ebuilds's test suite to verify post-install 
correctness, (yes, there is support for unit-sytle testing built into 
emerge) but I'm not sure the quality of those tests on libpq or 
postgresql.

> > > a) probably traditionally depended on the whole postgresql, maybe
> > >    since before libpq was an own package. ie. qt, dovecot, ...
> >
> > Have you confirmed these actually compile just against libpg?
>
> I'm still in the process. The lack of automatic cleanroom builds
> requires me to install an minimal jail before each build.
> (most of my gentoo systems actually have postgresql server running)

Again, just so you know about the tools available, check out catalyst's 
smokescreen/tinderbox target.

But, before you preform such tests, I'd think filing a bug to be premature.  
Make sure there's a fixable issue before you potentially break packages.

> > > 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.
> >
> > Are you sure this isn't bringing in postgresql to satisfy some
> > virtual?
>
> Which virtual should it be ? And why ?

I'm not sure, I didn't do any investigation, but it could be something as 
simple as virtual/db or virtual/storage.  If it's bringing in postgresql 
as a virtual, then it depends on postgresql OR any package that can 
provide that virtual, as controlled by (IIRC) <profile>/virtual 
plus /etc/portage/profile/virutual.  In that case, I don't believe the bug 
would be well-founded, because the dependent package (e.g. bugzilla) 
definitely needs *somewhere* to store it's data.

> > In all cases, you've confirmed that the dependency is direct and not
> > USE flag controlled?
>
> Of course, it is controlled by the postgresql useflag. But that doesn't
> make it better. Bugzilla does not need an local postgres server.
> And I didn't find any sign that it needs pg_config, so this current
> libpq bug also shouldn't be an issue.

USE-flags can bring in non-requisite dependencies, for convenience.  If you 
don't want a package to bring in the USE-flag dependent dependencies, 
simply disable the flag for that package.

That said, if a use flags controls both *support for* and a *dependency on* 
a certain package, it is broken, and I feel you bug could be valid.  E.g. 
package Y without the postgres USE flag can't use a remote postgresql 
server but package Y with the postgres USE flags forces you to install a 
local postgresql server.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh