#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