Joshua Root | 1 Aug 2010 10:24
Favicon

Re: variants not preserved on upgrade

On 2010-8-1 08:07 , Jeremy Huddleston wrote:
> I have boost installed as +python26+universal:
> $ port installed boost
> The following ports are currently installed:
>   boost  <at> 1.42.0_0+icu+python26+universal (active)
> 
> but when upgrading, it's trying to pull in openmpi (which is a variant that conflicts with python26).
> 
> $ cat .../.macports.boost.state 
> variant: +openmpi
> variant: +universal
> variant: +icu
> variant: +python26
> 
> 
> So why is it trying to add +openmpi to the variants when it explicitly conflicts? (yes it's in variants.conf)

We could probably be a bit smarter about not adding variants from
variants.conf when they conflict with what's already been requested, but
I don't know if it's as straightforward as it sounds. At present, if you
don't want +openmpi in this situation, you have to install with an
explicit -openmpi (which is then preserved when you upgrade).

- Josh
Arno Hautala | 1 Aug 2010 15:25
Favicon
Gravatar

Re: variants not preserved on upgrade

On Sun, Aug 1, 2010 at 04:24, Joshua Root <jmr <at> macports.org> wrote:
>
> At present, if you don't want +openmpi in this situation, you have to
> install with an explicit -openmpi (which is then preserved when you
> upgrade).

Is this true?  I thought negative variants were not currently stored
on install and therefore not honored during upgrades.

--

-- 
arno  s  hautala    /-|   arno <at> alum.wpi.edu

pgp eabb6fe6 d47c500f b2458f5d a7cc7abb f81c4e00
_______________________________________________
macports-dev mailing list
macports-dev <at> lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Jeremy Lavergne | 1 Aug 2010 16:51

Re: variants not preserved on upgrade

> Is this true?  I thought negative variants were not currently stored on install and therefore not honored
during upgrades.

That has changed since 1.9 was released, though with little fanfare.

Attachment (smime.p7s): application/pkcs7-signature, 2435 bytes
> Is this true?  I thought negative variants were not currently stored on install and therefore not honored
during upgrades.

That has changed since 1.9 was released, though with little fanfare.

David Baumgold | 1 Aug 2010 21:49
Favicon

ruby_select port

I wrote and currently maintain most of the Ruby 1.9 Gem ports currently in MacPorts (rb19-*). Recently, Joe Rozner emailed me informing me that my rb19-rails port didn't work properly: after a bit of debugging, I discovered that he was using the "ruby" executable to run it from the "ruby" port (Ruby version 1.8), rather than the "ruby1.9" executable from the "ruby19" port (Ruby version 1.9). With the Python ports, users can select default versions using the "python_select" port -- it would make a lot of sense to do the same thing for Ruby using a "ruby_select" port, but sadly, that port doesn't currently exist. There is a +nosuffix variant for the current "ruby19" port, but this is not a good solution -- not only does it conflict with the "ruby" port, but apparently some rb19-* Portfiles don't work with it (see http://trac.macports.org/ticket/25896).


I noticed that there is a "select" Portgroup which should make this Portfile easy enough to write: I've attached a draft Portfile which is more-or-less copied from the current python_select port. However, I don't really know what I'm doing, and I'm guessing that the "ruby" and "ruby19" ports are going to have to be modified for this to work -- and I don't maintain either of them. Can someone(s) point me in the right direction and/or help me get the ball rolling for this?
Attachment (Portfile): application/octet-stream, 1655 bytes
<div>
<p>I wrote and currently maintain most of the Ruby 1.9 Gem ports currently in MacPorts (rb19-*). Recently, Joe Rozner emailed me informing me that my rb19-rails port didn't work properly: after a bit of debugging, I discovered that he was using the "ruby" executable to run it from the "ruby" port (Ruby version 1.8), rather than the "ruby1.9" executable from the "ruby19" port (Ruby version 1.9). With the Python ports, users can select default versions using the "python_select" port -- it would make a lot of sense to do the same thing for Ruby using a "ruby_select" port, but sadly, that port doesn't currently exist. There is a +nosuffix variant for the current "ruby19" port, but this is not a good solution -- not only does it conflict with the "ruby" port, but apparently some rb19-* Portfiles don't work with it (see&nbsp;<a href="http://trac.macports.org/ticket/25896">http://trac.macports.org/ticket/25896</a>).</p>
<div>
<br>
</div>
<div>I noticed that there is a "select" Portgroup which should make this Portfile easy enough to write: I've attached a draft Portfile which is more-or-less copied from the current python_select port. However, I don't really know what I'm doing, and I'm guessing that the "ruby" and "ruby19" ports are going to have to be modified for this to work -- and I don't maintain either of them. Can someone(s) point me in the right direction and/or help me get the ball rolling for this?</div>
</div>
jul | 1 Aug 2010 22:24
Picon
Favicon

new ports submitted

Hello,

I've submitted many new ports
http://trac.macports.org/query?status=assigned&status=new&status=reopened&reporter=~jul_bsd&summary=~&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=port&order=priority

#25897  [NEW] security/log2timeline
#25898 	[NEW] security/volatility
#25899 	[NEW] net/nsm-console
#25900 	[NEW] net/chaosreader
#25901 	[NEW] net/pads
#25902 	[NEW] net/tcpdstat
#25903 	[NEW] net/tcpxstract
#25904 	[NEW] graphics/afterglow
#25905 	[NEW] graphics/*picviz*
#25906 	[NEW] net/openfpc

as I'm not used to, please test and comment.

Thanks a lot.
Best regards,

Jul
Ryan Schmidt | 2 Aug 2010 00:37
Favicon

Re: ruby_select port


On Aug 1, 2010, at 14:49, David Baumgold wrote:

> I wrote and currently maintain most of the Ruby 1.9 Gem ports currently in MacPorts (rb19-*). Recently,
Joe Rozner emailed me informing me that my rb19-rails port didn't work properly: after a bit of debugging,
I discovered that he was using the "ruby" executable to run it from the "ruby" port (Ruby version 1.8),
rather than the "ruby1.9" executable from the "ruby19" port (Ruby version 1.9). With the Python ports,
users can select default versions using the "python_select" port -- it would make a lot of sense to do the
same thing for Ruby using a "ruby_select" port, but sadly, that port doesn't currently exist. There is a
+nosuffix variant for the current "ruby19" port, but this is not a good solution -- not only does it
conflict with the "ruby" port, but apparently some rb19-* Portfiles
  don't work with it (see http://trac.macports.org/ticket/25896).
> 
> I noticed that there is a "select" Portgroup which should make this Portfile easy enough to write: I've
attached a draft Portfile which is more-or-less copied from the current python_select port. However, I
don't really know what I'm doing, and I'm guessing that the "ruby" and "ruby19" ports are going to have to be
modified for this to work -- and I don't maintain either of them. Can someone(s) point me in the right
direction and/or help me get the ball rolling for this?

Actually, "select" functionality is now built into MacPorts base but we appear not to have switched all our
select ports over to this new mechanism.

Ryan Schmidt | 2 Aug 2010 00:37
Favicon

Re: new ports submitted


On Aug 1, 2010, at 15:24, jul wrote:

> I've submitted many new ports
> http://trac.macports.org/query?status=assigned&status=new&status=reopened&reporter=~jul_bsd&summary=~&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=port&order=priority
> 
> #25897  [NEW] security/log2timeline
> #25898 	[NEW] security/volatility
> #25899 	[NEW] net/nsm-console
> #25900 	[NEW] net/chaosreader
> #25901 	[NEW] net/pads
> #25902 	[NEW] net/tcpdstat
> #25903 	[NEW] net/tcpxstract
> #25904 	[NEW] graphics/afterglow
> #25905 	[NEW] graphics/*picviz*
> #25906 	[NEW] net/openfpc
> 
> 
> as I'm not used to, please test and comment.

Thank you, I'm beginning to take a look and will provide feedback.

Jeremy Huddleston | 2 Aug 2010 07:48
Favicon

Re: variants not preserved on upgrade


On Jul 31, 2010, at 15:35, Rainer Müller wrote:

> On 2010-08-01 00:07 , Jeremy Huddleston wrote:
>> I have boost installed as +python26+universal:
>> $ port installed boost
>> The following ports are currently installed:
>>  boost  <at> 1.42.0_0+icu+python26+universal (active)
>> 
>> but when upgrading, it's trying to pull in openmpi (which is a variant that conflicts with python26).
> 
> I don't see any conflicts between +openmpi and +python26 in the output
> of `port variants boost` or in the Portfile. How did you come to this
> assumption?

>From the Portfile:

foreach s ${pythons_suffixes} {
    set p python${s}
    set v [string index ${s} 0].[string index ${s} 1] 
    set i [lsearch -exact ${pythons_ports} ${p}]  
    set c [lreplace ${pythons_ports} ${i} ${i}]
    eval [subst {
        variant ${p} description "Build Boost.Python for Python ${v}" conflicts ${c} debug {
            # Cannot build debug variants with openmpi and python variants as per the following:
            # <http://trac.macports.org/ticket/23667> and <https://svn.boost.org/trac/boost/ticket/4461>

Rainer Müller | 2 Aug 2010 10:15
Favicon

Re: variants not preserved on upgrade

On 2010-08-02 07:48 , Jeremy Huddleston wrote:
> From the Portfile:
> 
> foreach s ${pythons_suffixes} {
>     set p python${s}
>     set v [string index ${s} 0].[string index ${s} 1] 
>     set i [lsearch -exact ${pythons_ports} ${p}]  
>     set c [lreplace ${pythons_ports} ${i} ${i}]
>     eval [subst {
>         variant ${p} description "Build Boost.Python for Python ${v}" conflicts ${c} debug {
>             # Cannot build debug variants with openmpi and python variants as per the following:
>             # <http://trac.macports.org/ticket/23667> and <https://svn.boost.org/trac/boost/ticket/4461>

That only marks each +pythonXY as conflicting with the other python
variants and additionally with +debug, but not +openmpi.

--- snip ---

$ port variants boost
boost has the variants:
   debug: Builds debug versions of the libraries as well
     * conflicts with openmpi
...
   openmpi: Build Boost.MPI
     * conflicts with debug
...
   python26: Build Boost.Python for Python 2.6
     * conflicts with debug python24 python25 python27 python31

--- snap ---

No conflict between +openmpi and +python26, so I think port behaves
correctly at this point.

Rainer
Jeremy Huddleston | 2 Aug 2010 11:33
Favicon

Re: variants not preserved on upgrade

Ah, you're right...

Index: Portfile
===================================================================
--- Portfile	(revision 70213)
+++ Portfile	(working copy)
 <at>  <at>  -114,7 +114,7  <at>  <at> 
     set i [lsearch -exact ${pythons_ports} ${p}]
     set c [lreplace ${pythons_ports} ${i} ${i}]
     eval [subst {
-        variant ${p} description "Build Boost.Python for Python ${v}" conflicts ${c} debug {
+        variant ${p} description "Build Boost.Python for Python ${v}" conflicts ${c} debug openmpi {
             # Cannot build debug variants with openmpi and python variants as per the following:
             # <http://trac.macports.org/ticket/23667> and <https://svn.boost.org/trac/boost/ticket/4461>
             patchfiles-append   patch-tools-build-v2-tools-python.jam.diff
 <at>  <at>  -143,7 +143,7  <at>  <at> 
     build.args-append   -sICU_PATH=${prefix}
 }

-variant openmpi description {Build Boost.MPI} conflicts debug {
+variant openmpi description {Build Boost.MPI} conflicts debug universal {
     # Cannot build debug variants with openmpi and python variants as per the following:
     # <http://trac.macports.org/ticket/23667> and <https://svn.boost.org/trac/boost/ticket/4461>
     depends_lib-append  port:openmpi

On Aug 2, 2010, at 01:15, Rainer Müller wrote:

> On 2010-08-02 07:48 , Jeremy Huddleston wrote:
>> From the Portfile:
>> 
>> foreach s ${pythons_suffixes} {
>>    set p python${s}
>>    set v [string index ${s} 0].[string index ${s} 1] 
>>    set i [lsearch -exact ${pythons_ports} ${p}]  
>>    set c [lreplace ${pythons_ports} ${i} ${i}]
>>    eval [subst {
>>        variant ${p} description "Build Boost.Python for Python ${v}" conflicts ${c} debug {
>>            # Cannot build debug variants with openmpi and python variants as per the following:
>>            # <http://trac.macports.org/ticket/23667> and <https://svn.boost.org/trac/boost/ticket/4461>
> 
> That only marks each +pythonXY as conflicting with the other python
> variants and additionally with +debug, but not +openmpi.
> 
> --- snip ---
> 
> $ port variants boost
> boost has the variants:
>   debug: Builds debug versions of the libraries as well
>     * conflicts with openmpi
> ...
>   openmpi: Build Boost.MPI
>     * conflicts with debug
> ...
>   python26: Build Boost.Python for Python 2.6
>     * conflicts with debug python24 python25 python27 python31
> 
> --- snap ---
> 
> No conflict between +openmpi and +python26, so I think port behaves
> correctly at this point.
> 
> Rainer


Gmane