building conflicting packages from a single spec

Pádraig Brady P at draigBrady.com
Wed Nov 18 23:49:44 UTC 2015


On 18/11/15 22:34, Richard W.M. Jones wrote:
> On Wed, Nov 18, 2015 at 04:34:16PM +0000, Pádraig Brady wrote:
>> On 18/11/15 03:31, Jason L Tibbitts III wrote:
>>>>>>>> "PB" == Pádraig Brady <P at draigBrady.com> writes:
>>>
>>> PB> Is $subject possible?
>>>
>>> I don't think so, since at the end of %install you have exactly one set
>>> of files in one buildroot.
>>
>> Right. There was talk of potential support for this ages ago:
>> https://www.redhat.com/archives/rpm-list/2002-July/msg00222.html
>>
>>> Still, I don't see a reason for the
>>> subpackages to actually conflict.
>>>
>>> PB> Are any other techniques possible?
>>>
>>> Install the binaries under separate names and use simple scripts to
>>> decide which to run (or use alternatives, but ugh.)  Install libraries
>>> into separate paths and use the scripts to set the library path.
>>>
>>> If the software uses dlopen, just fix it to open the proper library
>>> based on the capabilities of the machine.
>>
>> Yes not ideal.
>> What I've done in %post is to mv the conflicting files
>> from a temp to standard location, overwriting any existing files.
> 
> That's horrible for supermin to deal with.  Can I ask at least that
> the non-single-file coreutils version (ie. the normal one) isn't the
> one which uses the %post script?

I didn't mention coreutils in this thread.
You don't miss much :)

Yes this is related to the coreutils split I was looking at.
I've come up with something fairly clean.
The normal coreutils package is unchanged.
coreutils-single is also now a "normal package" which will
not modify any installed files and thus verify correctly after install.
I was able to add new links in the %post stage to the packaged files,
leveraging the multicall binary handling.  It works well in a chroot at least.

cheers,
Pádraig.


More information about the devel mailing list