[MacPorts] #47255: making port:xz optionally independent of other ports

[MacPorts]

#47255: making port:xz optionally independent of other ports
--------------------------+--------------------------
  Reporter:  rjvbertin@…  |      Owner:  ryandesign@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:  haspatch
      Port:  xz           |
--------------------------+--------------------------
Changes (by larryv@…):

 * owner:  macports-tickets@… => ryandesign@…
 * cc: ryandesign@… (removed)


Old description:

> There is an option in etc/macports/macports.conf to create xz'ipped
> software archives for ports built locally. That gives a substantial
> reduction in the disk footprint of those archives, but also introduces a
> dependency issue.
>
> Xz depends on port:libiconv and port:gettext, and esp. the latter is
> updated rather frequently. The update sequence (when building from
> source) is as follows, taking gettext as an example (using xz compression
> and with the +universal variant which is the reason many of us have to
> build each upgrade from source):
>
> 1) port destroot gettext +universal
> 2) create the new archive in
> ${prefix}/var/macports/software/gettext/gettext???.txz
> 3) port deactivate gettext at current-version+universal
> 4) unpack the archive created in (2) in a temporary directory in
> ${prefix}/var/macports/software/gettext
>
> And that's where things go wrong: since port:gettext has been
> deactivated, port:xz can no longer function.
>
> The proposed enhancement allows to work around this by adding a default
> variant for xz, `+nls`. This default variant corresponds to the current
> situation, in which xz depends on libiconv and gettext to be
> "internationalised".
> Users who want to have xz compressed software archives can `port install
> xz -nls`, in which case said dependencies are dropped, and xz still
> functions when gettext or libiconv have been deactivated.
>
> Upgrading xz itself will remain a problem.
>
> The correct way to address this issue is of course to change the order of
> steps outline above:
>
> 1) port destroot xz +universal
> 2) create the new archive in ${prefix}/var/macports/software/xz/xz???.txz
> 3) unpack the archive created in (2) in a temporary directory in
> ${prefix}/var/macports/software/xz
> 4) port deactivate xz at current-version+universal
> 5) move the new files in place from the temporary directory into
> ${prefix}
>
> This has 2 advantages: 1) the to-be-updated functionality remains
> available right up to the moment where standard system commands will be
> used to update it, so that tools used in the procedure can update
> themselves and 2) the "gap" during which the to-be-updated functionality
> is unavailable is reduced to the strict minimum, which means users are
> unlikely to notice it even when they're running the update in the
> background. This "gap" can be quite lengthy for large ports like Qt.

New description:

 There is an option in etc/macports/macports.conf to create xz'ipped
 software archives for ports built locally. That gives a substantial
 reduction in the disk footprint of those archives, but also introduces a
 dependency issue.

 Xz depends on port:libiconv and port:gettext, and esp. the latter is
 updated rather frequently. The update sequence (when building from source)
 is as follows, taking gettext as an example (using xz compression and with
 the +universal variant which is the reason many of us have to build each
 upgrade from source):

 1. port destroot gettext +universal
 1. create the new archive in
 ${prefix}/var/macports/software/gettext/gettext???.txz
 1. port deactivate gettext at current-version+universal
 1. unpack the archive created in (2) in a temporary directory in
 ${prefix}/var/macports/software/gettext

 And that's where things go wrong: since port:gettext has been deactivated,
 port:xz can no longer function.

 The proposed enhancement allows to work around this by adding a default
 variant for xz, `+nls`. This default variant corresponds to the current
 situation, in which xz depends on libiconv and gettext to be
 "internationalised".
 Users who want to have xz compressed software archives can `port install
 xz -nls`, in which case said dependencies are dropped, and xz still
 functions when gettext or libiconv have been deactivated.

 Upgrading xz itself will remain a problem.

 The correct way to address this issue is of course to change the order of
 steps outline above:

 1. port destroot xz +universal
 1. create the new archive in ${prefix}/var/macports/software/xz/xz???.txz
 1. unpack the archive created in (2) in a temporary directory in
 ${prefix}/var/macports/software/xz
 1. port deactivate xz at current-version+universal
 1. move the new files in place from the temporary directory into ${prefix}

 This has 2 advantages: 1) the to-be-updated functionality remains
 available right up to the moment where standard system commands will be
 used to update it, so that tools used in the procedure can update
 themselves and 2) the "gap" during which the to-be-updated functionality
 is unavailable is reduced to the strict minimum, which means users are
 unlikely to notice it even when they're running the update in the
 background. This "gap" can be quite lengthy for large ports like Qt.

--

Comment:

 For what it’s worth, I don’t like this idea.

 1. Variants are generally undesirable.
 1. Frankly, we should not do anything to encourage people to use .txz
 archives until we make it reasonable to do so without the use of the `xz`
 port. As you already noted, systems that use .txz archives via the `xz`
 port would continue to break when `xz` itself is updated. The only stable
 way to address this would be to bundle xz with base.

-- 
Ticket URL: <https://trac.macports.org/ticket/47255#comment:1>
MacPorts <https://www.macports.org/>
Ports system for OS X