Changes between Initial Version and Version 1 of Ticket #47255


Ignore:
Timestamp:
Mar 24, 2015, 10:11:33 PM (9 years ago)
Author:
larryv (Lawrence Velázquez)
Comment:

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

  1. Variants are generally undesirable.
  2. 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.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #47255

    • Property Cc ryandesign@… removed
    • Property Owner changed from macports-tickets@… to ryandesign@…

  • Ticket #47255 – Description

    initial v1  
    33Xz 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):
    44
    5 1) port destroot gettext +universal
    6 2) create the new archive in ${prefix}/var/macports/software/gettext/gettext???.txz
    7 3) port deactivate gettext@current-version+universal
    8 4) unpack the archive created in (2) in a temporary directory in ${prefix}/var/macports/software/gettext
     51. port destroot gettext +universal
     61. create the new archive in ${prefix}/var/macports/software/gettext/gettext???.txz
     71. port deactivate gettext@current-version+universal
     81. unpack the archive created in (2) in a temporary directory in ${prefix}/var/macports/software/gettext
    99
    1010And that's where things go wrong: since port:gettext has been deactivated, port:xz can no longer function.
    … …  
    1717The correct way to address this issue is of course to change the order of steps outline above:
    1818
    19 1) port destroot xz +universal
    20 2) create the new archive in ${prefix}/var/macports/software/xz/xz???.txz
    21 3) unpack the archive created in (2) in a temporary directory in ${prefix}/var/macports/software/xz
    22 4) port deactivate xz@current-version+universal
    23 5) move the new files in place from the temporary directory into ${prefix}
     191. port destroot xz +universal
     201. create the new archive in ${prefix}/var/macports/software/xz/xz???.txz
     211. unpack the archive created in (2) in a temporary directory in ${prefix}/var/macports/software/xz
     221. port deactivate xz@current-version+universal
     231. move the new files in place from the temporary directory into ${prefix}
    2424
    2525This 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.