[MacPorts] #27588: users are not aware that xz-devel is outdated and they should replace it by xz

[MacPorts]

#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