rev-upgrade and checking for +universal dependencies (and build dependencies)

[René J.V. Bertin]

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