[MacPorts] #18314: ruby19 nosuffix variant
#18314: ruby19 nosuffix variant ----------------------------------+----------------------------------------- Reporter: jonbrenner@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: ruby19 suffix | Port: ruby19 ----------------------------------+----------------------------------------- The attached patch adds a "nosuffix" variant which removes the --program- suffix=1.9 configure arg. -- Ticket URL: <http://trac.macports.org/ticket/18314> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18314: ruby19 nosuffix variant ----------------------------------+----------------------------------------- Reporter: jonbrenner@… | Owner: febeling@… Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: ruby19 suffix | Port: ruby19 ----------------------------------+----------------------------------------- Changes (by jmr@…): * owner: macports-tickets@… => febeling@… -- Ticket URL: <http://trac.macports.org/ticket/18314#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18314: ruby19 nosuffix variant ----------------------------------+----------------------------------------- Reporter: jonbrenner@… | Owner: febeling@… Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: ruby19 suffix | Port: ruby19 ----------------------------------+----------------------------------------- Comment(by febeling@…): There are 2 reasons why I'm not so fond of that idea: - It would conflict with ruby 1.8 port - As things are, the variant would be lost with the next update, and that would mean the names of executables change with an upgrade. Are there strong reasons to add this still? -- Ticket URL: <http://trac.macports.org/ticket/18314#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
I used a "conflicts ruby" directive to prevent problems when the 1.8 port is active on a system. Would that work? I'm new to macports and wasn't sure whether the directive signals conflicts with other ports or just variants. Why would the variant get lost with the next update? As for the reason behind it, I am running 1.9 exclusively and prefer to have no program suffix. I thought the variant was a clean and appropriate way to accomplish that without managing symlinks to each binary distributed with the package (ruby, rdoc, rake, gem, ri, etc.). Jon On Sun, Feb 1, 2009 at 5:27 PM, MacPorts <noreply@macports.org> wrote:
#18314: ruby19 nosuffix variant
----------------------------------+----------------------------------------- Reporter: jonbrenner@… | Owner: febeling@… Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: ruby19 suffix | Port: ruby19
----------------------------------+-----------------------------------------
Comment(by febeling@…):
There are 2 reasons why I'm not so fond of that idea:
- It would conflict with ruby 1.8 port - As things are, the variant would be lost with the next update, and that would mean the names of executables change with an upgrade.
Are there strong reasons to add this still?
-- Ticket URL: <http://trac.macports.org/ticket/18314#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18314: ruby19 nosuffix variant ----------------------------------+----------------------------------------- Reporter: jonbrenner@… | Owner: febeling@… Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: ruby19 suffix | Port: ruby19 ----------------------------------+----------------------------------------- Comment(by jmr@…): Why would the variant be lost with the next update? The only known problem with the wrong variants being selected on upgrade is that default variants become re-selected if you had them deselected. -- Ticket URL: <http://trac.macports.org/ticket/18314#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18314: ruby19 nosuffix variant ----------------------------------+----------------------------------------- Reporter: jonbrenner@… | Owner: febeling@… Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: ruby19 suffix | Port: ruby19 ----------------------------------+----------------------------------------- Comment(by jonbrenner@…): Copied from the mailing list: I used a "conflicts ruby" directive to prevent problems when the 1.8 port is active on a system. Would that work? I'm new to macports and wasn't sure whether the directive signals conflicts with other ports or just variants. Why would the variant get lost with the next update? As for the reason behind it, I am running 1.9 exclusively and prefer to have no program suffix. I thought the variant was a clean and appropriate way to accomplish that without managing symlinks to each binary distributed with the package (ruby, rdoc, rake, gem, ri, etc.). -- Ticket URL: <http://trac.macports.org/ticket/18314#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18314: ruby19 nosuffix variant ----------------------------------+----------------------------------------- Reporter: jonbrenner@… | Owner: febeling@… Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: ruby19 suffix | Port: ruby19 ----------------------------------+----------------------------------------- Comment(by febeling@…): Replying to [comment:3 jmr@…]:
Why would the variant be lost with the next update? The only known problem with the wrong variants being selected on upgrade is that default variants become re-selected if you had them deselected.
If that is the case then I had a misconception here. Thanks for pointing out. That changes the picture a bit for this request. -- Ticket URL: <http://trac.macports.org/ticket/18314#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18314: ruby19 nosuffix variant ----------------------------------+----------------------------------------- Reporter: jonbrenner@… | Owner: febeling@… Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: ruby19 suffix | Port: ruby19 ----------------------------------+----------------------------------------- Comment(by febeling@…): Replying to [comment:4 jonbrenner@…]:
Copied from the mailing list:
I used a "conflicts ruby" directive to prevent problems when the 1.8 port is active on a system. Would that work? I'm new to macports and wasn't sure whether the directive signals conflicts with other ports or just variants.
nah, conflicts deals with other variants, not with ports.
Why would the variant get lost with the next update?
See Joshua's comment above. There is a bug with variants being dropped, but as Joshua points out above it is only under certain conditions, which I wasn't aware of. So I will have a fresh look at this tomorrow. Thanks for putting together and submitting a patch, btw! -- Ticket URL: <http://trac.macports.org/ticket/18314#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18314: ruby19 nosuffix variant -----------------------------------+---------------------------------------- Reporter: jonbrenner@… | Owner: febeling@… Type: enhancement | Status: closed Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Resolution: fixed | Keywords: ruby19 suffix Port: ruby19 | -----------------------------------+---------------------------------------- Changes (by febeling@…): * status: new => closed * resolution: => fixed Comment: r46306 -- Ticket URL: <http://trac.macports.org/ticket/18314#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (2)
-
Jonathon Brenner
-
MacPorts