Bug 191750 - [revive port] archivers/xz -> 5.0.5, MAINTAINERSHIP, MIRROR
Summary: [revive port] archivers/xz -> 5.0.5, MAINTAINERSHIP, MIRROR
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Many People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-08 20:38 UTC by jharris
Modified: 2015-03-22 12:23 UTC (History)
4 users (show)

See Also:


Attachments
patch (2.63 KB, patch)
2014-07-08 20:38 UTC, jharris
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jharris 2014-07-08 20:38:26 UTC
Created attachment 144522 [details]
patch

update ports version of archivers/xz to 5.0.5 (base version needs to catch up)
re-mirror DISTFILES
become MAINTAINER
Comment 1 Steve Wills freebsd_committer freebsd_triage 2014-07-09 21:02:14 UTC
Sorry, this port was removed from the ports tree in Jan 2014, perhaps your tree was out of date. It was removed because it's now included with the base OS. 11-CURRENT has the 5.0.5 version, so I don't think there's anything to do here. Let me know if I'm wrong.
Comment 2 jharris 2014-07-10 13:48:48 UTC
1.  Actually, I had to dig archivers/xz out of svn BECAUSE my ports tree is up to date, but...

2.  My still-supported/non-EoL/fully-patched base system has:

  %/usr/bin/xz --version
  xz (XZ Utils) 5.0.4
  liblzma 5.0.4

3.  And xz 5.0.5 was released on 2013-06-30, so the port (xz 5.0.4) was 6 months behind and should have been updated in 2014-01 rather than being deleted.

4.  And we have other ports that peacefully coexist with their base counterparts:

  a.  archivers/gzip
  b.  archivers/bzip2
  c.  ports-mgmt/pkg, pkg-devel
  d.  net/ntp, ntp-devel, ntp-rc
  e.  textproc/diffutils
  f.  textproc/flex
  g.  sysutils/file
  h.  plenty more to be found at http://svnweb.freebsd.org/base/head/contrib/

5.  And many of these ports are a necessity BECAUSE they're ahead of their base counterparts, e.g., file-5.11 -> file-5.19, again in my still-supported/non-EoL/fully-patched base system.

6.  And 11-CURRENT isn't a RELEASE, according to:

  http://www.freebsd.org/releases/

  So, you're telling me that NOBODY running a FreeBSD RELEASE at this time can have xz 5.0.5?!  Really?  Excellent merit^D^D^D^D^D^Dbureaucracy...
Comment 3 Steve Wills freebsd_committer freebsd_triage 2014-07-10 14:14:47 UTC
For reference, the differences between 5.0.4 and 5.0.4 are listed here:

http://git.tukaani.org/?p=xz.git;a=blob;f=NEWS;hb=HEAD#l124

I'll leave this PR open for someone else to work on if they have interest.
Comment 4 John Marino freebsd_committer freebsd_triage 2014-07-26 14:59:46 UTC
bapt, naddy, 
what do you think about jharris' case given that you two were involved with the port removal?

He has a good point about featuring bzip and bzip2 so why not xz? especially if it provides functionality not provided in base.

He probably should have stayed away from the wisecrack, but the rest of his argument is somewhat persuasive.
Comment 5 jharris 2014-07-26 20:11:45 UTC
Steve, sorry if my wisecrack offended you; it was only meant to make everyone reading it question the status quo.

Specifically, the repochurn from ports/archivers/xz's removal means I can't easily see, via "svn log" (in a resurrected version), when the port was deleted.  I had to 'svn annotate' ports/MOVED, assume the commits to the port and ports/MOVED were done at the same time - not always the case, and do some more hunting to get the port back in my tree.

In the future, if absolutely needed to prevent a hard collision between ports and BASE, it would be cleaner to use IGNORE (e.g., 9.2-RELEASE, until EoL/2015):

  %make
  ===>  xz-5.0.5 may conflict with "xz (XZ Utils) 5.0.4" in the base system.

This would prevent further churn caused by creating a -devel port, waiting for all supported FreeBSD base trees to catch up, probably deleting the -devel port if it stagnates for a while, and, if so, perhaps losing its easily-found history (svn log).

Thanks.
Comment 6 Christian Weisgerber freebsd_committer freebsd_triage 2014-07-27 18:36:38 UTC
(In reply to John Marino from comment #4)
> what do you think about jharris' case given that you two were involved with
> the port removal?

I think it is generally a bad idea to have something both in ports and in base, at least if libraries are involved.  Depending on the vagaries of the include and linker path, ports build on a system with both installed will pick up either the one or the other quasi-randomly.  This is particularly bad if the port and base have different versions!

xz is very stable and I don't see why users of older releases would have to have xz 5.0.5 NOW rather than waiting for it to trickle through from -CURRENT.
Comment 7 jharris 2014-07-31 14:12:22 UTC
Of course, there are precedents for installing alongside base and overwriting base, e.g., OpenSSL and openssh-portable, respectively.

In base, I see bsd{cpio,tar,grep}, lz*/lzma*, unzip, and xz* in /usr/bin, and pkg in /usr/sbin all use liblzma.so[.5].

Ports users of liblzma include aria2, opendnssec, php55, pixz, pkg, and libxml2, so far.

Hmm, ports/ports-mgmt/pkg can't be told where to find liblzma...  :(
Comment 8 Bartek Rutkowski freebsd_committer freebsd_triage 2015-03-08 21:09:08 UTC
Given the 11-CURRENT now has xz in version 5.2.0 and the 10.1-RELEASE has it in version 5.0.5, I think this PR can be closed. Anyone against it?
Comment 9 Bartek Rutkowski freebsd_committer freebsd_triage 2015-03-22 12:23:59 UTC
Closing this PR since there was no objections against doing so in last 2 weeks and the original idea was rejected due to the xz being in base.