Found this while revdep-rebuild recompiled android-sdk-update-manager: * Found some broken files that weren't associated with known packages * The broken files are: * /opt/android-sdk-update-manager/platform-tools/aapt Reproducible: Always
(In reply to comment #0) > * Found some broken files that weren't associated with known packages > * The broken files are: > * /opt/android-sdk-update-manager/platform-tools/aapt Very likely put there by the update manager itself, while running as root.
Yup - if you don't want files on your system not managed by portage, then don't run the android sdk update manager... :) I don't really see any clean solution to this - I don't like the design but it is what it is. The Android SDK itself is not FOSS, so we can't rebundle it either. However, perhaps something can be done with the AOSP code as an alternative SDK if this really matters to somebody... Unless somebody has a good suggestion for a way around this I'll probably close this in a few days...
Can't you tell revdep-rebuild to ignore the file? An Android project will not run in Eclipse without it. Who cares where the file came from; it's required.
(In reply to comment #3) > Can't you tell revdep-rebuild to ignore the file? An Android project will not > run in Eclipse without it. Who cares where the file came from; it's required. This works for me: $ mv /opt/android-sdk-update-manager/platform-tools/aapt /tmp/ $ revdep-rebuild -v -- --ask $ mv /tmp/aapt /opt/android-sdk-update-manager/platform-tools/
Sorry - I follow your argument now - I was missing your point. I agree, this is a binary package and should be masked from revdep-rebuild. I'll add the appropriate mask to /etc/revdep-rebuild in a few days...
Ok, -r2 should fix your problem. Let me know if it does not.
Thanks, I'll test it as soon as -r2 hits the portage tree.
This is not correctly fixed - the solution in 8-r2 was to add the following revdep-rebuild exclusion mask: SEARCH_DIRS_MASK="/opt/android-sdk-update-manager/" This should be the follow otherwise it doesn't omit sub-directories: SEARCH_DIRS_MASK="/opt/android-sdk-update-manager" A bit of a bugger, eh? Please could you release an r3? Thanks! :)
# revdep-rebuild * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 100% ] * broken /opt/android-sdk-update-manager/platform-tools/aapt (no version information available) * Generated new 3_broken.rr * Assigning files to packages * !!! /opt/android-sdk-update-manager/platform-tools/aapt not owned by any package is broken !!! * /opt/android-sdk-update-manager/platform-tools/aapt -> (none) * Generated new 4_raw.rr and 4_owners.rr * Found some broken files, but none of them were associated with known packages * Unable to proceed with automatic repairs. * The broken files are listed in 4_owners.rr with app-portage/gentoolkit-0.3.0_rc11-r3 and dev-util/android-sdk-update-manager-8-r2 on ~amd64
# ldd /opt/android-sdk-update-manager/platform-tools/aapt /opt/android-sdk-update-manager/platform-tools/aapt: /lib32/libz.so.1: no version information available (required by /opt/android-sdk-update-manager/platform-tools/aapt) linux-gate.so.1 => (0xf77a3000) librt.so.1 => /lib32/librt.so.1 (0xf776f000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7756000) libz.so.1 => /lib32/libz.so.1 (0xf7743000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libstdc++.so.6 (0xf7654000) libm.so.6 => /lib32/libm.so.6 (0xf762f000) libgcc_s.so.1 => /lib32/libgcc_s.so.1 (0xf7614000) libc.so.6 => /lib32/libc.so.6 (0xf74b5000) /lib/ld-linux.so.2 (0xf77a4000)
FYI - I'm not ignoring this - had a bit of a family emergency and I'll get this cleaned up as soon as I can... Reopening so that I don't forget about it...
Included fix in -9. Let me know if it has any issues.
