BUG: variants ignored in deps action

[gwhitney@…]

I installed MacPorts from 1.4.0 tarball, and successfully executed

sudo port selfupdate

to upgrade to 1.4.3. Now, executing

port deps emacs-devel +x11

(for example) yields output

emacs-devel has library dependencies on:
        ncurses

But this is clearly wrong: emacs-devel +x11 also depends on jpeg, tiff, libpng, perhaps among other things.

[gwhitney@…]

Proposed patch against r25303 to resolve this issue

[gwhitney@…]

The changes in r25033 and r25255 now make it easy to fix this bug: all that has to happen is for action_deps to share the code eridius put in action_info which does dportopen to get the "real" portinfo. That's the gist of this patch. There are two other points worth noting:

1. A couple places in this patch it's handling an attribute called "portvariants". This goes hand-in-hand with my patch for the registry bug (see ticket #11920) where the active variants are recorded in portvariants right at dportopen time; but these changes are innocuous if that patch has not been applied. If it has, they show, for example, in port deps, what variants are active, since the answer depends on that information.

2. In the same vein, since other information in port info depends on the active variants, there's a small patch to portutil.tcl which appends the active variants to the long_description, together with their descriptions if any. I think this clarifies the other output of port info, and is a nice proposed compromise between showing all variant descriptions and showing none: just show the active ones. That way, if you explicitly request port info foo +bar, you will see the description of variant bar, which I think makes sense. However, this chunk of the patch, the only chunk in portutil.tcl, is completely independent of the rest of the patch and can be eliminated if the developers disagree with this idea of modifying the long_description.

Thanks!

[jberry@…]

Glen,

Nice work. Let's get you a commiter account so you can work to get this stuff working in trunk.

One comment: it would seem useful to make action_variants also use the current port, rather than the index, in parallel with info and deps. The fact that info and variants now return information from different sources is probably wrong.

[gwhitney@…]

I did think about action_variants, and my conclusion was that it's illegitimate for one variant to add or delete other variants, that's what you use requires and conflicts for between variants, which must all be defined at the top level. So therefore the variants list in the index must be correct. If anyone has a different argument to the contrary, I'd be happy to put the dportopen stuff in action_variants as well.

[gwhitney@…]

OK, since my documentation patch was checked in by another maintainer (thanks!) I'm switching to using this patch as my first effort to properly check in a change to base. But I've split off point 2 in the 5/17/07 comment as a separate RFE ticket #12081, since it's logically distinct from this bugfix. I will only apply the portions of the patch relating to making port deps read the portfile with variants to get its dependency information.

[eridius@…]

I haven't had time to properly evaluate your patch, but the description sounds good. From your last comment it sounds like maybe you're working towards getting committer status, and thus want to commit this yourself? If that's not the case, let me know and I'd be happy to test and commit it.

Oh, and I would recommend pulling action_variants from the portfile if you're pulling the other info. Yeah, the index should match the portfile, but what if I update my portfile add a new variant? The index will be out of date until the next portindex run.

[gwhitney@…]

Yes, I do now have committer status, and I was planning on using this as my first try at a commit, since it's pretty small, self-contained, easy to test, etc. It's going a bit slow since I'm getting used to Subversion (which actually I want to use through SVK, since being able to make local branches is a real help if I'm working on more than one ticket at once), and because I want to really be careful with testing and understand that thoroughly as well (since there doesn't seem to be any fully standardized, documented, comprehensive pre-check-in testing protocol out there).

So if this isn't urgent and folks (like you, eridius) are willing to wait a bit I would appreciate the opportunity to check this one in myself. Further, I will include the portfile-reading stuff in action_variants as well, as per your convincing argument of why that's a better idea than relying on the index. Regards, Glen

[jmr@…]

Cc reporter of duplicate #12258.

[jmr@…]

Cc reporter of duplicate #12275.

[jmr@…]

Are you still planning on committing this, Glen?

[blb@…]

Attaching a new diff for base/src/port/port.tcl to enable handling variants for 'port deps'; this one just copies what is currently done for 'port info' so not much to it really.

[blb@…]

diff to base/src/port/port.tcl (on trunk)

[raimue@…]

Cc Me!