[gentoo-amd64] Re: revdep broken x11-drivers/ati-drivers net-nds/openldap

[Duncan]

"Daiajo Tibdixious" <daiajo@×××××.com> posted
a4a9bfcb0701301537h3bf84b89wbea47bf769e793ce@××××××××××.com, 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

-- 
gentoo-amd64@g.o mailing list