[MacPorts] #27588: users are not aware that xz-devel is outdated and they should replace it by xz
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ---------------------------------+------------------------------------------ Reporter: vinc17@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: xz xz-devel ---------------------------------+------------------------------------------ There's no reason that users should remain with xz-devel 4.999.9beta_0 instead of installing xz 5.0.0_0, and they cannot be aware of this new version with "port outdated". -- Ticket URL: <https://trac.macports.org/ticket/27588> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ---------------------------------+------------------------------------------ Reporter: vinc17@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: xz xz-devel ---------------------------------+------------------------------------------ Comment(by afb@…): This is the same for all pre-release "development" ports that the user has chosen to install. -- Ticket URL: <https://trac.macports.org/ticket/27588#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ---------------------------------+------------------------------------------ Reporter: vinc17@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: xz xz-devel ---------------------------------+------------------------------------------ Changes (by afb@…): * version: 1.9.2 => Comment: But since someone already added explicit `conflicts`, why not add `replaced_by` too ? -- Ticket URL: <https://trac.macports.org/ticket/27588#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ---------------------------------+------------------------------------------ Reporter: vinc17@… | Owner: afb@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: xz xz-devel ---------------------------------+------------------------------------------ Changes (by ryandesign@…): * owner: macports-tickets@… => afb@… * cc: ryandesign@… (added) Comment: Sure, I added `conflicts` indicators, because the ports do conflict. :) If you'd like instead to mark xz-devel as replaced_by xz, that would be a fine thing to do. -- Ticket URL: <https://trac.macports.org/ticket/27588#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ----------------------------------+----------------------------------------- Reporter: vinc17@… | Owner: afb@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: Port: xz xz-devel | ----------------------------------+----------------------------------------- Changes (by afb@…): * status: new => closed * resolution: => fixed Comment: Fixed, r74169. -- Ticket URL: <https://trac.macports.org/ticket/27588#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ----------------------------------+----------------------------------------- Reporter: vinc17@… | Owner: afb@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: Port: xz xz-devel | ----------------------------------+----------------------------------------- Comment(by afb@…): Pretty much all the development ports conflict with their stable counterparts, so adding explicit conflicts is somewhat redundant especially if they already have implicit file conflicts. But it's a pretty strange way to version things, either way. -- Ticket URL: <https://trac.macports.org/ticket/27588#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ----------------------------------+----------------------------------------- Reporter: vinc17@… | Owner: afb@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: Port: xz xz-devel | ----------------------------------+----------------------------------------- Comment(by ryandesign@…): Replying to [comment:4 afb@…]:
Fixed, r74169.
Also, the version needs to be increased, and users need to be prevented from attempting to install the port, and all the lines relating to installing the port can be removed. r74172. Replying to [comment:5 afb@…]:
Pretty much all the development ports conflict with their stable counterparts,
Yes they do.
so adding explicit conflicts is somewhat redundant
Adding explicit conflicts is absolutely necessary; it prevents a user from wasting time building a port if it won't be able to activate anyway due to conflicting files.
especially if they already have implicit file conflicts.
Which implicit file conflicts are you talking about?
But it's a pretty strange way to version things, either way.
What is? -- Ticket URL: <https://trac.macports.org/ticket/27588#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ----------------------------------+----------------------------------------- Reporter: vinc17@… | Owner: afb@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: Port: xz xz-devel | ----------------------------------+----------------------------------------- Comment(by afb@…):
so adding explicit conflicts is somewhat redundant
Adding explicit conflicts is absolutely necessary; it prevents a user from wasting time building a port if it won't be able to activate anyway due to conflicting files.
Well, it does activate if the new/stable one is deactivated.
especially if they already have implicit file conflicts.
Which implicit file conflicts are you talking about?
Your "conflicting files", above. As in they both install bin/xz
But it's a pretty strange way to version things, either way.
What is?
Separating two versions of a piece of software by changing name. Upgrading from 4.999.9beta to 5.0.0 is more of a "version" thing ? So ports systems are pretty strange, that way. Not everything is. I have no idea how the new xz-devel works, so I'll unmaintain it. -- Ticket URL: <https://trac.macports.org/ticket/27588#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
#27588: users are not aware that xz-devel is outdated and they should replace it by xz ----------------------------------+----------------------------------------- Reporter: vinc17@… | Owner: afb@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: Port: xz xz-devel | ----------------------------------+----------------------------------------- Comment(by ryandesign@…): Replying to [comment:7 afb@…]:
Adding explicit conflicts is absolutely necessary; it prevents a user from wasting time building a port if it won't be able to activate anyway due to conflicting files.
Well, it does activate if the new/stable one is deactivated.
Which implicit file conflicts are you talking about?
Your "conflicting files", above. As in they both install bin/xz
That's the exclusive purpose of the `conflicts` keyword -- to identify ports that want to install the same files. The ports system assumes only one port will ever install any particular file; the `conflicts` keyword is the mechanism by which ports can be tagged to override this assumption, to provide a better user experience.
But it's a pretty strange way to version things, either way.
What is?
Separating two versions of a piece of software by changing name.
Upgrading from 4.999.9beta to 5.0.0 is more of a "version" thing ?
So ports systems are pretty strange, that way. Not everything is.
Well, 4.999.9beta was a development version. 5.0.0 is a stable version. In cases where we want to maintain both a development version and a stable version of a software in MacPorts, we maintain separate foo-devel and foo ports. c.f. php5 & php5-devel, graphviz & graphviz-devel, pango & pango- devel, cairo & cairo-devel, libpixman & libpixman-devel, glib2 & glib2-devel, minivmac & minivmac-devel, etc. In the case of xz, we have the more unusual circumstance of having had a development version of a port before, and wishing to discontinue it and replace it with a stable version, so we have to go through some acrobatics to support that.
I have no idea how the new xz-devel works, so I'll unmaintain it.
It works in these ways: * `replaced_by` tells MacPorts that when a user tries to upgrade the port, it will instead install its replacement. * increasing `version` causes the old port to appear in the output of "port outdated", thus prompting the user to run "port upgrade" and initiate the above process. * clearing `distfiles` makes "port fetch" not attempt to download anything. * since there are no distfiles and the port doesn't install anything anymore, `master_sites`, `checksums`, patchfiles, dependencies, configure, build and destroot arguments, variants, and conflicts are deleted * a message is printed in pre-configure so that anyone attempting to install the port will be informed of its replacement. * `livecheck.type` is set to none since this port's version never needs to be updated again. Once all users can reasonably be expected to have run "sudo port sync" and "sudo port upgrade xz-devel" (to cause xz-devel to go away and xz to be installed in its place), xz-devel can be deleted. I typically recommend this not be done until at least one year in the future, since some users upgrade very infrequently. -- Ticket URL: <https://trac.macports.org/ticket/27588#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts