As db.h is already present in FreeBSD's /usr/include, it shouldn't be changed with the portage's version as it can be something different. The attached patch applied over current eclass removes the symlinking. It shouldn't (hopefully) break anything, but probably needs tests before getting in portage. Thoughts? Diego
Created attachment 65614 [details, diff] Eclass patch
I'd prefer one that would just conditionally not apply this for freebsd. Something like adding "if use freebsd; then".... "fi" I'm sure this will break enough packages, although a strict db installation would probably not provide /usr/include/db.h nor /usr/lib/db.so
how about symlinking only, if the file is not present? On Linux that would happen once (the first time the eclass is used) and on FreeBSD never. Or am I missing something?
It's only symlinking anyway. However the symlinking happens everytime that any db package is merged or unmerged. The eclass will maintain the links that are shared between the different versions.
Then just do a simple little trick: if ${ROOT}/usr/include/db.h does not exists or is a link, proceed as is now. If instead is a true file (as it happens on FreeBSD), don't touch it.
Paul can you say something about this? It's the only main issue remaining right now...
Ping..
Created attachment 85984 [details] New db.eclass Could you try out the attached db.eclass? It should work. It basically checks whether the files are symlinks or nonexistent. If so the symlinks will be created. Otherwise they will be left alone.
Created attachment 85991 [details] db.eclass That triggets syntax errors, this one has the same logic but it's parsed correctly, and yes it works correctly, thanks Paul :)
Thanks for testing it out for me. Feel free to commit it. (If you want me to do it, just say so).
Thanks, I've committed it.
