Обсуждение: Re:RPM dependencies (Was: 7.0 vs. 7.1 (was: latest version?))
[BCC to Hackers -- cc: to PORTS, as, as Bruce correctly pointed out, that's where this discussion belongs.] Trond Eivind Glomsrød wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > My gut feel is that RedHat may be better off shipping 7.0.x if the > > library version numbers are a contributory problem. > We could provide compat-packages with just neeeded libraries. Yes, we could do that. And those libs could possibly just be the symlinks (or even just a Provides: header). > We upgrade everything from 3.0.3 (we no longer support upgrades from > 2.0 as we couldn't find a specific way to identify such a system and > we didn't want accidentaly upgrade other distributions), so there is > pain anyway. I tried going from 4.1 (the earliest one I have installation CD's for) to pre-7.0 once. I don't recommend it. > > Of course, that doesn't affect what I do as far as building 7.1 RPM's > > for distribution from the PostgreSQL site (or by anyone who so desires > > to distribute them). I have no choice for my own self but to stay on > > the curve. I need TOAST and OUTER JOINS too much. > Others very likely have the same need. I'll be looking into issues > with these later. Good. Let me know what you decide, if you don't mind. > Anyway, I've had a look at psql in objdump: > Dynamic Section: > NEEDED libpq.so.2.1 > NEEDED libreadline.so.4.1 > [...] > It links against nice, round versions of most libraries but wants > specific versions of readline ad libpq. And unfortunately PHP and other PostgreSQL clients also link against the specific libpq version. This has caused pain for those installing the PHP stuff from RPM which was linked against a RedHat 6.2 box with PostgreSQL 6.5.3 installed -- onto a RedHat 6.2 box with PostgreSQL 7.0.2 installed. There is a failed dependency on libpq.so.2.0 -- even though libpq.so.2.1 is there. A symlink works around the problem, if the symlink is part of the RPM so that it gets in the rpm dep database. Of course, this only causes problems with RedHat 6.2 and earlier, as RH 7's PHP stuff was built against 7.0.2 to start with. But, 7.1 with libpq.so.2.2 will cause similar dep failures for PHP packages built against 7.0.2. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> And unfortunately PHP and other PostgreSQL clients also link against the > specific libpq version. This has caused pain for those installing the > PHP stuff from RPM which was linked against a RedHat 6.2 box with > PostgreSQL 6.5.3 installed -- onto a RedHat 6.2 box with PostgreSQL > 7.0.2 installed. There is a failed dependency on libpq.so.2.0 -- even > though libpq.so.2.1 is there. > > A symlink works around the problem, if the symlink is part of the RPM so > that it gets in the rpm dep database. Of course, this only causes > problems with RedHat 6.2 and earlier, as RH 7's PHP stuff was built > against 7.0.2 to start with. But, 7.1 with libpq.so.2.2 will cause > similar dep failures for PHP packages built against 7.0.2. For us, it would be great if libpq.so.2.1 linked against the libpq.so.2.1, libpq.so.2.2, but not libpq.so.2.0. I would guess other apps need this ability too. How do they handle it? I saw someone installing pgaccess from RPM. It wanted tcl/tk 8.0, and they had tcl/tk 8.3 installed, and it failed. Seems this is a common RPM problem. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian wrote: > > A symlink works around the problem, if the symlink is part of the RPM so > > that it gets in the rpm dep database. Of course, this only causes > > problems with RedHat 6.2 and earlier, as RH 7's PHP stuff was built > > against 7.0.2 to start with. But, 7.1 with libpq.so.2.2 will cause > > similar dep failures for PHP packages built against 7.0.2. > For us, it would be great if libpq.so.2.1 linked against the > libpq.so.2.1, libpq.so.2.2, but not libpq.so.2.0. I would guess other > apps need this ability too. How do they handle it? If I were doing manual dependencies for the other packages, I would say: Requires: libpq.so => 2.1 No as to whether that works or not, I don't know. I know it won't work with RPM prior to 3.0.4 or so. > I saw someone installing pgaccess from RPM. It wanted tcl/tk 8.0, and > they had tcl/tk 8.3 installed, and it failed. Seems this is a common > RPM problem. Well, actually, there are times you might not want greater than a certain version. And you as a packager can make certain dependency requirements manually. However, this libpq.so.2.0 vs 2.1 failure was an automatic dependency. And, really, RPM shouldn't allow it for automatic requires. Suppose I have an ancient client RPM that I want to install. Assuming for one second that nothing else has changed on the system except the PostgreSQL version, if the client was built against PostgreSQL 6.2.1 with libpq.so.1, and I force the install of it even though libpq.so.2 is installed, freakish things can happen. Been there and done that -- a client linked against Postgres95 1.0.1 did really strange things when libpq.so.2 was link loaded under it. Worse things happen if you have a package that requires tcl 7.4 and you have tcl 8.3.2 installed. Not everyone is as generous as we are with upwards compatibility. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11