On Sunday 24 December 2006 19:37, Enrico Weigelt <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> 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
pgpSdzUNAnO0M.pgp
Description: PGP signature
