[MacPorts] #44494: p5.xx-modul -> is macports creating another "RPM" hell?
#44494: p5.xx-modul -> is macports creating another "RPM" hell? -----------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.1 Keywords: | Port: -----------------------------+-------------------------------- One of the charming aspects of MacPorts has been the avoidance of "RPM hells", i.e. there was -- at least in the past -- just on version of a tool installed and a simple upgrade kept the system up-to-date. Now, with versioning in place, we have to face for example: {{{ $ port search p5.\* Found 5732 ports. p5.8-yaml @0.900.0 (perl) YAML loader/dumper module p5.10-yaml @0.900.0 (perl) YAML loader/dumper module p5.12-yaml @0.900.0 (perl) YAML loader/dumper module p5.14-yaml @0.900.0 (perl) YAML loader/dumper module p5.16-yaml @0.900.0 (perl) YAML loader/dumper module p5.18-yaml @0.900.0 (perl) YAML loader/dumper module p5.20-yaml @0.900.0 (perl) YAML loader/dumper module Found 7 ports. }}} Therefore a request for clarification whether McPorts is still in-line with it's original ideas? Why are we faced here with so many Perl versions? -- Ticket URL: <https://trac.macports.org/ticket/44494> MacPorts <http://www.macports.org/> Ports system for OS X
#44494: p5.xx-modul -> is macports creating another "RPM" hell? ------------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.1 Resolution: | Keywords: Port: | ------------------------------+-------------------------------- Comment (by egall@…): This has come up on the mailing lists a whole bunch of times... Pretty much everyone agrees that the current way of doing perl ports needs to be fixed, but so far we seem to have failed to come to an agreement about ''how'' exactly we actually need to go about doing this fixing... -- Ticket URL: <https://trac.macports.org/ticket/44494#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#44494: p5.xx-modul -> is macports creating another "RPM" hell? ------------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.1 Resolution: | Keywords: Port: | ------------------------------+-------------------------------- Comment (by ora.et.labora@…):
Pretty much everyone agrees that the current way of doing perl ports needs to be fixed, [..]
I used Perl as an example, it was not only about Perl. I'm getting flooded with various "versions" of mysql, php, python, ruby, gcc et cetera. Why the need for mysql, mysql5, mysql56 and so on? And if so, why not have "mysql" as base reference, i.e. always refers to the latest version. Now, this is obviously not the right place to discuss/brainstorm about. I believe I just misused this ticket to elaborate, that I'm getting (once a while()bit frustrated with MacPorts. -- Ticket URL: <https://trac.macports.org/ticket/44494#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#44494: p5.xx-modul -> is macports creating another "RPM" hell? ------------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.1 Resolution: | Keywords: Port: | ------------------------------+-------------------------------- Comment (by larryv@…): Replying to [comment:2 ora.et.labora@…]:
I'm getting flooded with various "versions" of mysql, php, python, ruby, gcc et cetera. Why the need for mysql, mysql5, mysql56 and so on?
There’s always a valid argument to be made for allowing ports to depend on specific versions of other ports, for stability. We usually don’t find this necessary, which is why MacPorts doesn’t really support it. We patch ports to work with newer libraries, report bugs upstream, and so on. It’s annoying, but less annoying than versioning. However, some software changes so much between versions and is critical to so much other software that we //have to// keep multiple versions around, or a ton of other stuff would break. Compilers (`gcc*`, `clang*`, `llvm*`), language implementations (`python*`, `perl*`, `ruby*`), and databases (`mysql*`, `postgresql*`) are the usual culprits. Perl is a special case; it’s sufficiently backwards-compatible that we’re considering going back to providing only one Perl.
And if so, why not have "mysql" as base reference, i.e. always refers to the latest version.
In practice, no one’s thought about doing that, and many versioned ports already use `port select` to let users achieve similar functionality. For example, `sudo port select --set python python34` creates several symlinks (such as `$PREFIX/bin/python`) that point to specific files provided by `python34`. Having a “latest” port sounds nice, until it updates on you and breaks everything horribly. (Imagine if we’d had a `python` port when the PSF released Python 3.) If a particular piece of software wouldn’t have this problem, then it shouldn’t have versioned ports to start with. -- Ticket URL: <https://trac.macports.org/ticket/44494#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#44494: p5.xx-modul -> is macports creating another "RPM" hell? ------------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.1 Resolution: | Keywords: Port: | ------------------------------+-------------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) * type: request => defect Comment: Replying to [comment:3 larryv@…]:
However, some software changes so much between versions and is critical to so much other software that we //have to// keep multiple versions around, or a ton of other stuff would break. Compilers (`gcc*`, `clang*`, `llvm*`), language implementations (`python*`, `perl*`, `ruby*`), and databases (`mysql*`, `postgresql*`) are the usual culprits.
Right. If for example you are a web site designer and you've written a web site with php 5.3 and mysql 5.1, it's possible that upgrading to php 5.5 and mysql 5.6 would break your site. You may not have time right now to fix your site to be compatible with the newer versions, or you may have designed the site for a client who is not paying you to make these changes. In these cases you may want to be able to stay on the older versions for that site, while still allowing you to simultaneously install and use newer versions for newer sites. The current configuration of ports in MacPorts makes this possible. With mysql we have the added issue that some users are disenchanted with the notion that mysql is now owned by oracle, prompting both the original developer of mysql and others to fork mysql, so we now additionally have the mariadb and percona ports from which users can choose. In all ports that use mysql, we should offer variants for the user to choose which of these they want to use, and we should have a consistent default. That's tracked generally in #39961 and in a few other tickets for some individual ports. Any further discussion should probably occur on the mailing lists. -- Ticket URL: <https://trac.macports.org/ticket/44494#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#44494: p5.xx-modul -> is macports creating another "RPM" hell? ------------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: base | Version: 2.3.1 Resolution: invalid | Keywords: Port: | ------------------------------+-------------------------------- Changes (by jmr@…): * status: new => closed * resolution: => invalid Comment: Closing, not because this isn’t a valid discussion to have, but simply because the bug tracker is not the right place for it. -- Ticket URL: <https://trac.macports.org/ticket/44494#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts