On Jul 23, 2014, at 9:52 AM, Michael Dickens wrote:

> I think there's a bug in the way port does "outdated", or maybe an 
> enhancement is needed in this regard.  I wanted to patch nds2-client via:
> 
> {{{
> Index: Portfile
> ===================================================================
> --- Portfile  (revision 122521)
> +++ Portfile  (working copy)
> @@ -124,6 +124,7 @@
>     # The Octave dependency can be satisfied by either octave or octave-devel.
>     depends_lib-append              path:bin/octave:octave
>     destroot.args-append            
> pkgoctexecdir="${prefix}/share/octave/site/m"
> +    revision                        1
> }
> 
> set need_sqlite 0
> }}}
> 
> which just bumps the revision if octave is required, either via the 
> +mex_octave or +swig_octave variant.  With this change, "port outdated" does 
> not show that this port needs to be updated.  If I move the "revision" into 
> the 2 variants, I get the same result.  I did execute "portindex" between 
> these commands to make sure the change was registered; the only version that 
> worked is the one I committed.
> 
> So, it seems like "port outdated" is not checking for updates via the 
> installed variants, just the core port / subport without variants.
> 
> Since this port is pretty small, I just moved the revision to the top-level.  
> But, this would be an interesting enhancement IMHO if it is not a bug. - MLD

You're right that the revision (and version and epoch) line needs to appear in 
the global part of the portfile, not inside a variant. That's not necessarily a 
bug...

In your case it's not in a variant but inside a conditional which checks 
whether variants are set. That might be confusing, but remember that MacPorts 
parses the port multiple times. I guess on the first pass variants aren't 
considered.

The epoch/version/revision are recorded into the portindex once for each port, 
not for each variant, so that seems like a good explanation for why the 
epoch/version/revision cannot be changed based on variants.


_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to