Created attachment 400408 [details, diff] Patch for ed-1.11.ebuild Upstream recommends using the .tar.gz distfile at fossies.org: https://lists.gnu.org/archive/html/bug-ed/2015-01/msg00004.html This would get rid of the dependency on the lzip unpacker which is used for little else than ed.
IIRC this is the same guy who also develops lzip. The last time I got in contact with him requesting one of his package also being released as gzip/xz tarball I got disappointing feedback [1]. So I 1) do _not_ want to rely on his daily mood for creating a differently compressed tarball of his sources. 2) do not want to ask him for such a tarball each time he releases a new version of his softwares. 3) do not want to always re-compress the tarball Feel free to find someone fulfilling your request but I won't do it. To be honest I don't see the reason for such a workload when you can just install lzip and be done with it. [1] http://lists.gnu.org/archive/html/bug-ddrescue/2013-10/msg00019.html
should be all set now in the tree; thanks for the report! Commit message: Switch to gzip as lzip is uncommon, and not that much smaller for this package http://sources.gentoo.org/sys-apps/ed/ed-1.11.ebuild?r1=1.1&r2=1.2
(In reply to Lars Wendler (Polynomial-C) from comment #1) > IIRC this is the same guy who also develops lzip. Yes he is, and AFAIK his packages are the only ones distributed in that uncommon format. (See bug 249059 comment #6 and following for his advocacy to add package manager support for lzip unpacking.)
(In reply to Lars Wendler (Polynomial-C) from comment #1) if there's a .gz available, lets use it, but otherwise i don't think we'll want to make one ourselves. i've also interacted with him in the past and it wasn't exactly fruitful.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3e846fa4b82dbcba6025faffcde18ee6bdea4b3c commit 3e846fa4b82dbcba6025faffcde18ee6bdea4b3c Author: Sam James <sam@gentoo.org> AuthorDate: 2022-02-07 01:17:48 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-02-07 01:21:43 +0000 sys-apps/ed: add 1.18 Go back to using lzip. Upstream only provide lzip archives (and indeed the maintainer of ed is the maintainer of lzip) and repacking to avoid a BDEPEND for a relatively unpopular package is overkill. Bug: https://bugs.gentoo.org/545344 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/ed/Manifest | 1 + sys-apps/ed/ed-1.18.ebuild | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+)
Reopening. Rationale still applies.
Closing again given the explanation in comment 5.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7713a9f0fc204a09d6b2a57a46e520f07bed72be commit 7713a9f0fc204a09d6b2a57a46e520f07bed72be Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-13 21:02:58 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2022-12-14 10:16:17 +0000 unpacker.eclass: support >=app-arch/xz-utils-5.4.0 for lzip decompression >=app-arch/xz-utils-5.4.0 supports lzip decompression (not compression). Add support for unpacker.eclass to handle it for .lz files. Note that xz-utils is part of @system (and PMS requires that .xz is unpackable), while most users do not have lzip and friends installed. (Note that xz does not (currently, but does not plan on either) implement parallel decompression for .lz, but most .lz distfiles are small, so this isn't an issue.) Historically, we've often repacked .lz distfiles for important packages to avoid users needing to install app-arch/lzip for a single distfile, so this avoids the need for that (although I've not done it out of principle for things like sys-apps/ed). Bug: https://bugs.gentoo.org/249059 Bug: https://bugs.gentoo.org/485462 Bug: https://bugs.gentoo.org/501912 Bug: https://bugs.gentoo.org/502990 Bug: https://bugs.gentoo.org/545344 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Michał Górny <mgorny@gentoo.org> eclass/unpacker.eclass | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-)
