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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
