"Daiajo Tibdixious" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 31 Jan 2007 10:37:05 +1100:
>>> This case is probably an example of one of the issues with >>> revdep-rebuild, or more precisely with binary-only packages you may >>> choose to run. > > I know it freaks on firefox-bin. I resent that "choose" to run, as its > only ignorance at work here, are you saying openldap is binary? AFAIK I > don't have any binary packages any more. No. I was still talking about the ATI video drivers still. As with Nvidia, the driver has some open code but some closed binary-only code as well. I dealt with openldap (to the limited degree I could) further down, below where I quoted your mention of it. >> Revdep-rebuild sees and scans the shared libraries, and doesn't know >> when they are part of a binary-only package. Naturally, you can remerge >> the binary-only package all day and if it was built against a library >> not on your system, it's not going to help one bit. > > Yeah, I figured that out with firefox-bin, how does it apply here? I'm assuming some of the binary-only ATI video driver shared libraries are linked against something you don't have on the system. If so, it'll be difficult to fix since you can't just recompile them, the ebuild just remerges the same binary stuff each time so it doesn't help. >>> Newer revdep-rebuild versions have a way to configure it to ignore >>> certain packages. > > I'm used to ignoring revdep-rebuild. :) Especially I ignore the packages > to be rebuilt, its great for detecting broken linkage but lousy (in my > limited experience) at fixing them. I've had better luck with it, but that may be simply due to the fact that I keep up pretty closely with ~arch, updating twice a week to daily, keep the system generally cruft free, don't run anything binary-only (with a single exception, the close to a decade and a half old now 1993 original Master of Orion, tho at least I run it on from-source DOSBOX) >>> standard gripe about slaveryware here, but it's your system, not mine, >>> so you get to choose what you run and I'd not deny you that right, >>> regardless of how much I gripe.) > > I'd rather not have slaveryware either. My son has a Win XP Home which I > use for that. :( If I were to be a gamer, I expect I'd run a Wii for my proprietary/gaming stuff and still wouldn't install anything binary-only on my computer. If you aren't using the 3D stuff on your video card anyway, you may wish to see if the native xorg driver will run it. It doesn't run the newest chips, but it does thru the ATI r300 series chips now in 3D and beyond that in 2D, I believe. Again, it's your system, and I'd not tell you what you had to run even if I could, but if the native will work for what you do with the system, it's /definitely/ less hassle. I know I got /so/ tired of dealing with Nvidia's drivers (which I had to use at the time, as the native ones didn't handle the second video output on the card and I was multi-monitor, before I actually switched to Linux, when I got the card, I knew enough to ensure twinview worked in Linux, which I planned to switch to, but didn't realize there were closed drivers at the time, so made a purchase decision I regretted badly after I actually switched to Linux and learned the hassle it meant) and was /so/ glad to get off it and get an ATI Radeon with full native support. >>> > openldap >> >>> Did you try rebuilding [] anything else that might > > I removed it, put it back by --usepkg and rebuild, several times. > kdebase is pulling it in, amoung other things: # equery depends -d > openldap [ Searching for packages depending on openldap... ] > dev-libs/cyrus-sasl-2.1.22-r1 > app-crypt/gnupg-1.4.6 > app-crypt/gnupg-1.9.21 > net-misc/curl-7.15.1-r1 > net-misc/openssh-4.5_p1 > kde-base/kdebase-3.5.5-r1 > > hmm, made a lier out of myself. I haven't rebuilt any of these. One of those apparently still depends on the old ldap library. >> BTW2, I'm a KDE guy myself but have (some of) the split packages >> merged, not monolithic (as I think I mentioned before). > > I've wondered about that, going split sound like it might be less > trouble, I'll look into it. I do it for a couple reasons. 1) When there's a security update or the like, as long as it's not kdelibs (where the monolithic package is used in both cases), it's usually just one or two packages out of the big monolithic package I'd otherwise have to rebuild, so those sorts of between-KDE version upgrades go MUCH faster, 2) It allows me to pick and choose the packages I actually use. For instance, I don't have a handheld, so I don't need all those packages out of kdepim, but I DO run kmail, so I have it and its support merged -- but without the handheld junk I'd be spending all that time compiling for nothing if I ran the monolithic package. Of course, that means that security updates or the like for packages I don't have merged don't force a recompile of the whole big thing either -- I don't have to worry about them since I don't have them merged! =8^) All that said, there's one negative as well. When the packages are split, that means most of what was the single ./configure step in the monolithic package now gets run many times, once for each of the split packages. If you just merge kde now, and do the exact parallel with kde-meta, thus merging /all/ the packages in the monolithic, it takes much longer to do full KDE version upgrades, because of all that duplicated ./configure work. Thus, unless you know there are a number of packages you definitely don't use and can therefore skip merging, it may be best to stick with the monolithics. In my case, there are whole swatches of several of the monolithics that I don't use at all and would prefer not to have on the system (can't cause security or admin issues if they aren't there!), so the extra time spent in the duplicated ./configure steps during the merge is more or less canceled out by the number of packages I don't merge at all, and it takes about the same time for the full KDE version upgrades, while taking much less time for security updates and the like, AND avoiding all that extra cruft on the system, so the split packages are a definite net positive for me even with that negative. As I said, tho, it wouldn't be nearly as clear-cut for those simply merging kde-meta instead of kde, and I'm not sure I'd recommend it unless you DO plan on using the splits to skip a number of individual packages you aren't interested in. >> you have on that I have off. You don't happen to have the the ldap USE >> flag on, do you? It doesn't sound like you'd be using it. It's off >> here. >> > Its not present. I just checked... the kdebase monolithic package does indeed have an ldap USE flag. It looks like the split package that pulls it in is kdebase-kioslaves, which has the flag as well. Looking at the ebuild, the openldap dependency is indeed conditional on the ldap flag. Since I have -ldap, I skipped that dependency. If you don't have -ldap, the profile is probably setting +ldap for you. Yes, I just checked, it's turned on by default in $PORTDIR/profiles/default-linux/amd64/2006.1/desktop in any case, so probably is in other similar profiles as well. If you don't need ldap, which you probably don't unless you are part of a corporate network that uses it or deliberately set it up on your home network, I'd suggest setting -ldap in make.conf, thus overriding the profile. An emerge -N world should then remerge anything that uses that USE flag, and hopefully kill all your dependencies on it, allowing you to unmerge it and not worry about it any more. A quick check on the packages you listed says they all have the ldap USE flag, so indeed, one presumes toggling it off and remerging them will remove that dependency. > Anyway, I'm happy now, I'll just ignore the broken links, since I'm not > using them. I'll put up with it & hope the next version of openldap is > more consistent. I don't like ignoring such things if I don't have to, and it shouldn't be necessary except on binary packages. If you're not using openldap anyway, the above should remove it as a dependency, after which you can unmerge it and cure the problem. =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
