Binary downloads

Blair Zajac blair at orcaware.com
Tue Apr 10 20:46:09 PDT 2012


On 04/10/2012 08:39 PM, Blair Zajac wrote:
> On 04/10/2012 08:38 PM, Joshua Root wrote:
>> On 2012-4-11 13:28 , Blair Zajac wrote:
>>> More questions.
>>>
>>> How are variants handled for dependent packages?
>>
>> The same way they're handled normally.
>>
>>> For example, I add a bunch of default variants to variants.conf that has
>>> perl5.* compile using +shared +threads and if this changes Perl's ABI,
>>> then how are the dependent binary Perl modules handled?
>>
>> Badly, just as though you installed a bunch of perl modules and then
>> rebuilt perl with +shared +threads. You can't depend on a variant.
>>
>>> Actually, a better example is Python, I compile with +ucs4 which changes
>>> the functions for managing Unicode and if a binary module is loaded into
>>> a Python with +ucs2, then things will fail with missing symbols.
>>>
>>> Should binary downloads be disabled if a reverse-dependent package has a
>>> non-default variant set?
>>
>> Ports that require their dependencies to be built with specific variants
>> should be fixed.
>
> Thanks for the fast answers Josh, I appreciate it.

What about the idea of having a Boolean flag on a variant if it changes 
the ABI of a package that would break a dependent package.  Enabling 
+doc on a package shouldn't effect any dependants, but adding +ucs4 to 
any python* will break any py{2,3}* modules.  Then port could check if 
it's safe to download a binary package.  Variants could be made by 
default "ABI-unsafe" to promote maintainers to mark their variants as 
"ABI-safe" for binary downloads.

Of course, it gets harder than this, since git-core depends upon 
p5.12-term-readkey, but it doesn't care how Perl was compiled, just 
perl5.12 and p5.12-term-readkey need to be consistent.  Same with 
Python, I don't think git-core cares how python27 was compiled.

I don't know if there's a perfect system, but a system that would allow 
binary downloads and save you from breakage that may not happen sounds 
like a good idea, even if it prevents you from making use of a binary 
download.

Blair


More information about the macports-dev mailing list