For some (binary) packages a rebuild is always recommended

[cjk]

Hey there, thanks for making this little useful tool!

For some packages, it will always indicate a rebuild, even if they were freshly installed / upgraded. Probably mostly binary packages, like Dropbox etc.

Example:

$ ~/scripts/checkrebuild.sh -v
mypkgs  dropbox
mypkgs  google-musicmanager

ldd /opt/dropbox/librsyncffi_native.cpython-37m-x86_64-linux-gnu.so

    librsync.so.1 => not found

ldd /opt/dropbox/apex._apex.cpython-37m-x86_64-linux-gnu.so

    libdropbox_apex.so => not found

ldd /opt/dropbox/libQt5Core.so.5

    libicui18n.so.42 => not found
    libicuuc.so.42 => not found
    libicudata.so.42 => not found

ldd /opt/dropbox/libQt5WebKit.so.5

    libicui18n.so.42 => not found
    libicuuc.so.42 => not found
    libicudata.so.42 => not found
[...]

Not sure there is anything to do about it?

[maximbaz]

Hey :) Hmm on the one hand I can imagine dropbox knows to search for those libraries in some non-standard location which ldd is unaware of (which I think you could workaround using LD_LIBRARY_PATH=... checkrebuild), on the other hand there is little point in this as you aren't able to rebuild binary packages anyway.

I think the easiest way is to ignore these binary packages, i.e. just checkrebuild | grep -v XXX.

These packages shouldn't bug you during pacman hook because they are leaf dependencies and nothing depends on them, so it's only necessary to filter them out if you use checkrebuild manually or part of some personal automation. Is my assumption correct? 🙂

[cjk]

@maximbaz Yes, that sounds reasonable. Those BLOB-packages are always bumped by version-number anyways. Let's close this and thanks for your prompt response on this!

[jazz-it]

I also just stumbled upon this issue. Even you recommended us to ignore such issues for leaf dependencies, it would be interesting to know what causes it and is there a way to avoid it?

$ checkrebuild             
foreign dsf2flac-git
foreign gifcurry
foreign google-earth-pro
foreign python-crcmod
foreign python-ffmpeg
foreign python-sip-pyqt4
foreign r128gain
foreign trimage

[maximbaz]

you can run checkrebuild -v and it will show the reason for why they are flagged 😉

[jazz-it]

Here's the output: https://pastebin.com/YZJm6SYT

[maximbaz]

So as you can see you have a few packages that were built for previous python (3.8) that probably need to be rebuilt against python 3.9, and a bunch of packages that are linked against some shared library, but that shared library is missing. checkrebuild is printing the command it ran, so e.g. you can also run ldd /usr/bin/dsf2flac directly and it will print all the linked libraries, and there you will see that some are missing. As to why this happens, I'm not 100% sure but I believe it happens because when the binary was compiled, this library was present, but now it's absent - especially possible if you are using a binary that someone else compiled, like in -bin packages. Hope that makes sense?

[jazz-it]

Perfect, thanks. All of those packages were installed from AUR, therefore all of the packages were compiled on my machine. So, in order to resolve my issue, I will need to rebuild those packages against the new python version (3.9). I just re-installed gifcurry from AUR, but the issue is still there. My Python is on 3.9.1. I guess the solution is to contact the maintainers of those packages and ask them to make such modifications on their end, so the new installation would be able to use the appropriate new libraries.

[maximbaz]

Stuff that is placed in /opt is usually not compiled on your own machine, if you look at PKGBUILD of gifcurry you can see that it's not being compiled on your computer, it just downloads pre-compiled binary from github and copies it onto your computer. So those libs probably are present on the computer of whoever compiled the binary 🤔

[jazz-it]

Hmmm... good catch! Thanks! Makes me worried at the same time.

[maximbaz]

So yeah I agree with you, while in some cases there is not much that you can do except to ignore such packages, it can definitely be interesting to first go through them all and understand exactly why they are flagged in the first place 😄

[jazz-it]

Agreed, thanks. This discussion helped me to understand from which direction a boogeyman comes from and why is he coming. :smile:

[edmundlaugasson]

Having similar issue - https://clbin.com/02ui7 - after updating, rebuilding, rebooting still these packages remain...

$ checkrebuild
foreign protonmail-bridge-bin
foreign zoom
foreign ventoy-bin
foreign vlc-luajit
foreign vmware-horizon-client
foreign vmware-horizon-usb

[maximbaz]

As you can see, a bunch of required dependencies are "not found", the advice is still the same as above, either to try fixing the packages, adding the missing deps, or simply ignoring these packages on your end with checkrebuild | grep -v. Some of them, like -bin, are not compiled on your machine, so it's possible that you won't be able to solve the underlying problem on your own, and ignoring is the only possibility - see also the thread above. Hope that helps!

[edmundlaugasson]

OK, I see. I'm not capable of fixing these packages, I can only announce in AUR about that need. For now, I ignore these. Created file ~/broken-pkg

$ cat broken-pkg 
protonmail-bridge-bin
zoom
ventoy-bin
vlc-luajit
vmware-horizon-client
vmware-horizon-usb

Then I can check: checkrebuild | grep -evf broken-pkg

[maximbaz]

Hello, someone suggested to me an interesting workaround to significantly reduce number of false positives for -bin packages: https://github.com/maximbaz/rebuild-detector/commit/d785805a24db1d08c702e540c033645888f05a3f

Marking it as "experimental", if someone can tell me why doing this is a bad idea, I'd very much like to know. I hope by doing this we will not mask some real problems. Any feedback welcome.

But for now, with that patch if checkrebuild outputs some packages, it's even more likely that they are just packaged wrongly.

[Fabian42]

In my case checkrebuild always complains for insync that libpcre.so.3 can't be found. That file is in /usr/lib/insync. Can it not see that folder for some reason? I've also tried LD_LIBRARY_PATH=/usr/lib/insync checkrebuild, that instead prints a ton of error messages about pacman, pacconf, etc.. I guess it can't access other libraries it needs anymore then, but that's weird, because before that command, LD_LIBRARY_PATH was unset/empty.

[maximbaz]

It is weird. To give you more details, checkrebuild itself is not looking for any folders, it simply executes ldd /path/to/bin, you can run that command directly (and you'll see the same output as when you run checkrebuild -v), so that is all to say, the tricks to search are on how to make ldd command find all the necessary libraries.

[Fabian42]

[fabian@laptop ~]$ whereis insync
insync: /usr/bin/insync /usr/lib/insync /usr/share/man/man1/insync.1.gz
[fabian@laptop ~]$ ldd /usr/bin/insync 
        not a dynamic executable