On Thursday June 04 2015 07:23:24 Ryan Schmidt wrote: > On Jun 4, 2015, at 06:08, René J.V. Bertin wrote: > > > > > On Thursday June 04 2015 05:02:03 Ryan Schmidt wrote: > > >> You can always reinstall python27 without the universal variant and see if > >> something breaks. > > > > Well, that's what I've done, and I haven't yet found any breakage. I'm just > > concerned that at some point this means I'll be facing a re-install of the > > universal variant, possibly with a whole slew of py27 packages. At least > > I'll know which port is responsible then... > > Well if you figure out which port you're building universal that depends on > python27 but doesn't require it to be universal, we can add > depends_skip_archcheck to it then.
I see dbus has a bunch of build dependencies in its test variant that could be a candidate for such an operation, but I don't think I ever installed that variant. And while I'm at it: port:git seems to be a candidate for installs_libs=no . > They are all useful. DIdn't intend to imply they're not. > You misunderstand. Apparently ... the danger with undocumented features O:-) > depends_skip_archcheck is not a new type of dependency. > depends_skip_archcheck does not declare a dependency. Rather, it specifies > that an existing dependency does not need to have its architectures verified. > So if you want to declare a build dependency on python27 and that > architectures don't matter, you would write (untested): > > depends_build-append port:python27 > depends_skip_archcheck-append python27 That's not how I have used the keyword; I've used it to declare a dependency not declared in any other way, and that just worked as far as I can tell. Maybe there's a check that adds an implicit depends_lib when adding a new dependency through depends_skip_archcheck? > Yes, one could modify the python ports to have the interpreter in a separate > subport from the libraries. I think that'd be counterproductive; as Joshua points out you cannot avoid having a universal interpreter (or its entry point). I don't know what you'd be using it for (interactively, I mean; using the same MacPorts tree on a 32bit and a 64bit VM perhaps?), but that is not actually different from any other application. No, what I had in mind is provide a way to refer to the interpreter that does not take the architecture into account. R _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
