Problem/Motivation

ArchiveTar.php is unmaintained and unmaintainable because it is exempt from all coding standards, yet cannot be documented as external code.

Proposed resolution

With composer.json, we have the opportunity to cleanly bring in external components. Let's remove our unmaintained fork of Archive_Tar and move to Lootils Archiver.

Remaining tasks

Get an RTBC patch.

User interface changes

Nothing changes for the User Interface.

API changes

The API now uses Lootils\Archiver rather than Drupal\Compoenents\Archiver. It has a very similar interface, but allows us to keep external sources external and bring them in cleanly.

Related

CommentFileSizeAuthor
#4 1673246.patch317.44 KBrobloach
#2 1673246.patch105.29 KBrobloach
lootils.patch101.37 KBrobloach

Comments

Status: Needs review » Needs work

The last submitted patch, lootils.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

Updated issue summary.

robloach’s picture

Status: Needs work » Needs review
StatusFileSize
new105.29 KB
robloach’s picture

Issue summary: View changes

Updated issue summary.

Status: Needs review » Needs work

The last submitted patch, 1673246.patch, failed testing.

robloach’s picture

Status: Needs work » Needs review
StatusFileSize
new317.44 KB

Here's the correct patch... Hopefully.

robloach’s picture

Issue summary: View changes

Updated issue summary.

robloach’s picture

Assigned: Unassigned » robloach
sun’s picture

So we are replacing one fork with another? What's the point of that?

I'm also very skeptical on pulling random stuff from the net into Drupal core. It makes sense to do that if there is a larger, active project and developer community behind some code. But if that is not the case, how well is the code maintained? How many non-merged forks are around? How long does the project exist, and does anyone else actually use it?

It looks like this component was created by someone of the Drupal community. That inherently leads to the question why we aren't making Drupal\Components its origin instead?

patcon’s picture

@sun I'm not sure, but I think this a @RobLoach and @mfer's repo. I think the suggestion is just to manage it like an external lib as composer allows. But I don't have the full backstory, so it's just a guess :)

@RobLoach Not sure of the history behind Archiver, so can't comment directly, but if we were to use an external library, might it make sense to pull in one that is actually forked from the official?
https://github.com/pear/Archive_Tar

Seems a large part of the benefit of pulling in the repo with composer is that it can have it's own history that's easily traced to the canonical repo. This allows us to pull official changes into our fork in a more transparent way.

Maybe flag @chx and host it here so there's less confusion:
https://github.com/drupal

Or not sure where d.o stands in terms of hosting non-modules. Maybe that's better?

patcon’s picture

Issue summary: View changes

Updated issue summary.

slashrsm’s picture

slashrsm’s picture

Let's resurrect this from the ashes... :)

I think that it makes sense to pull in an external library even if it's author comes from the Drupal community. We already have such cases after all.

Lootils\Archiver seem to have more releases, while pear/Archive_Tar actually has some pulls (2 closed and 1 open). The latter is obviously a bit older, which means it has more history (and users I assume?). It seems like we forked pear/Archive_Tar since we wanted to replace default PHP with corresponding drupal_* functions. I'm not sure how to deal with this if we decide for Lootils\Archiver, as it seems it is the same situation there. One advantage of Lootils\Archiver seems to be support for various archive types (Tar & Zip), which could probably help us to kill even more code.

Having an unmaintained fork seems the worst option to me, though.

longwave’s picture

Can we rely on (or require) the PHP Phar extension when we want to deal with tar files? "It is possible to create and manipulate regular zip and tar files using the PharData class [...]": http://www.php.net/manual/en/class.phardata.php

robloach’s picture

PharData class

Great idea, longwave. Would allow interacting with .phar files the same way you would a .zip file. Added an issue to Lootils\Archiver:
https://github.com/lootils/archiver/issues/3

droplet’s picture

alansaviolobo queued 4: 1673246.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 4: 1673246.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

robloach’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

This goes back.