Spending output of a low-fee transaction by following with higher-fee transaction Suppose I broadcast a transaction A with very low (or zero) fee. Normally, it would take a long time to confirm. Suppose, then I broadcast another transaction B that spends a (yet unconfirmed) output of the first transaction A and includes normal or higher-than-normal fee. I assume that the transaction B can be mined only in the same or later block than the transaction A. Would the higher fee of the transaction B be motivating for miners to mine the transation A as well?

Or, put it in different words, can I facilitate a confirmation of a low-fee transaction by spending its output using a high-fee transaction? If yes, what Bitcoin client would allow me to do that?
There are 3 cases.

Case 1a:
if Fee(Tx1) &lt; Dust Fee then Tx1 gets dropped by nodes that do not offer Free Relay Policy. Then all other transaction dependent on the outputs of Tx1 will never be committed to the blockchain, even though descendent transactions may or may not be accepted into the mempool of a subset of nodes in the network. 

Case 1b:
if Fee(Tx1) > Dust Fee &amp;&amp; Fee(Tx1) &lt; Recommended Tx Fee then Tx1 will be accepted by mempool but eventual commitment is at risk. In this case, It is possible to boost fee rate by contributing more transaction fees, as described by 2quick 4u using CPFP, where Tx2 will contain a higher transaction fee than Tx1, lifting the mean fee rate which includes the ancestor transaction, Tx1.

Case 2: if Fee(Tx1) > Dust Fee &amp;&amp; Fee(Tx1) >= Recommended Tx Fee then Tx1 gets accepted by nodes. All dependent transactions dependent on the outputs of Tx1 should eventually be committed to the blockchain, so as long as the fee rate for the root and dependent transactions are competitively high enough to be selected and committed to the blockchain. The reason why should is bolded is because a competitive fee rate is constantly changing based on demand in the network. So one will expect the fee rate to be significantly higher when the network is busy and vice-versa. Furthermore, there is usually a 72 hour limit on pending transactions that are in the mempool. Once 72 has elapsed and a transaction has yet be committed, it will be dropped from the mempool.