Re: [PATCH 1/2] rpm.eclass: switch order of rpm and rpm2targz

On 30/03/2026 21:24, Sam James wrote:
> Nowa Ammerlaan <[email protected]> writes:
> 
>> Since app-arch/rpm is the official implementation prefer using that
>> if it is installed. We keep app-arch/rpm2targz as the default in the
>> dependencies since it is more lightweight.
> 
> I think it looks like a bug for the two to be inconsistent and someone
> will end up correcting it in future. It should have a comment or better
> yet, just make the two match, at least for now (so put rpm first in the
> dep too).

Well, in my opinion, it actually makes more sense to have the if/else/fi 
in the opposite order compared to the dependency because if we consider 
that app-arch/rpm2targz is the "default" as communicated by the 
dependency. Then, the special action that is required to use the 
non-default (emerge app-arch/rpm) should actually respect that choice, 
and thus the app-arch/rpm unpacker should be used.

For me, the intuitive thing would be to have "the default" in the else 
clause. But as I said earlier, I am also open to solving the problem 
differently, with for example some switch in the eclass. Though I do 
feel a dedicated switch is a bit of an overkill for such a simple problem.

I am actually not convinced the problem we encounter in the linked bug 
will be fixed in app-arch/rpm2targz anytime soon. The latest version is 
from March 2021, the only resolvable url in the SRC_URI is our mirror, 
and I cannot find a source repository let alone a bug tracker (though 
admittedly I did not search for very long). Honestly, if 
app-arch/rpm2targz wasn't significantly more lightweight compared to the 
full app-arch/rpm I would have proposed to just remove the choice and 
leave only the "official" app-arch/rpm.

> 
>>
>> This also allows ebuilds which have some issue with
>> app-arch/rpm2targz to BDEPEND on app-arch/rpm to ensure the working
>> implementation is pulled in and used. Such an incompatibility is
>> currently only observed in app-backup/tsm-8.2.1.0 which appears to
>> contain an encrypted(?) payload.
> 
> We have https://bugs.gentoo.org/971578 too, I think?
> 
> I've not verified it's related but I'm fairly sure it is.

I've tested this but I find no difference between using app-arch/rpm or 
app-arch/rpm2targz, with either unpacker I cannot reproduce this bug. I 
suspect the root cause is something else.

> 
>>
>> See-also: 26b30e180a4b2583452508d79ebb35d0e97fc696
>> Bug: https://bugs.gentoo.org/971600
>> Signed-off-by: Nowa Ammerlaan <[email protected]>
>> ---
>>   eclass/rpm.eclass | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/eclass/rpm.eclass b/eclass/rpm.eclass
>> index 3b7f9e64355b..97106741fe7d 100644
>> --- a/eclass/rpm.eclass
>> +++ b/eclass/rpm.eclass
>> @@ -43,11 +43,11 @@ rpm_unpack() {
>>   			a="${DISTDIR}/${a}"
>>   		fi
>>   
>> -		if command -v rpm2tar >/dev/null; then
>> -			local extracttool=(rpm2tar -O)
>> -		else
>> -			# app-arch/rpm fallback
>> +		if command -v rpm2archive >/dev/null; then
>>   			local extracttool=(rpm2archive -n)
>> +		else
>> +			# app-arch/rpm2targz fallback
>> +			local extracttool=(rpm2tar -O)
>>   		fi
>>   
>>   		"${extracttool[@]}" "${a}" | tar xf -