Can a smart contract B force a revert on receiving eth from another contract A and bug this contract? Is sending eth safe generally for a smart contract if the receiver is a contract address?

That's the default behaviour of a contract. It cannot receive eth unless there's a receive,fallback or any payable function

that's not my question. Does sending eth to a contract like this would result in a revert from sending contract or not, and generally is sending ether to another contract a safe operation from the sender perspective (can it bug the code of sending contract) by forcing a revert for example

Uhh... Isn't that what I just answered. You simply cannot send eth to a contract from an eoa/another contract if the receiver contract doesn't explicitly have fallback/receive function implemented

you can revert by specifying it in the fallback function, but you can still be forced to receive it if it does get sent with selfdestruct.

Apart from forcing ether into a contract bypassing fallbacks

Contract A will selfdestruct before call to contract B gets reverted?

Still not my question

You can revert in B sure but can you force A to revert from B

It doesn't get reverted with selfdestruct

so yeah apparently it does cause a revert in contract A. i assumed ether transfers were of a different nature than external function calls. That's really dangerous if your contract logic has to transfer succesfully to be able to go on. The next step is to prevent sending ether to a smart contract

is require(msg.sender == tx.origin) sufficient to guarantee 100% the caller isn't a contract

No

so what are the options left to prevent a smart contract from interacting with a function