Maybe you could consider providing a repackaged tarball on gentoo mirrors? It doesn't save space if users have to install lzip for unpacking of one package only. Alternatively, upstream could be asked to continue providing gzip compressed tarballs, or switch to xz.
Well providing a repackaged tarball could be done as a last resort. But I can ask upstream to provide gz/xz compressed tarballs as well.
One month ping. Any news?
(In reply to Ulrich Müller from comment #2) > One month ping. Any news? Sorry. I completely forgot about this bug. I sent a request to ddrescue mailing list today (see URL). Let's wait for their reply.
>=sys-apps/ed-1.10 is now distributed as lz tarball only, too.
(In reply to Christoph Junghans from comment #4) > >=sys-apps/ed-1.10 is now distributed as lz tarball only, too. Yes, same upstream maintainer as ddrescue. :-(
unpacker_src_uri_depends() added to ddrescue's ebuild too, it was missing from both sys-apps/ed and sys-fs/ddrescue, while otherwise already converted to unpacker.eclass http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/ddrescue/ddrescue-1.17-r1.ebuild?r1=1.2&r2=1.3 nothing left to do here, closing
Not fixed.
(In reply to Ulrich Müller from comment #7) > Not fixed. $ emerge -p =sys-fs/ddrescue-1.17-r1 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-arch/lzip-1.15 96 kB [ebuild N ~] sys-fs/ddrescue-1.17-r1 USE="-static" 63 kB Total: 2 packages (2 new), Size of downloads: 158 kB What is the problem?
(In reply to Christoph Junghans from comment #8) > (In reply to Ulrich Müller from comment #7) > > Not fixed. > $ emerge -p =sys-fs/ddrescue-1.17-r1 > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild N ] app-arch/lzip-1.15 96 kB > [ebuild N ~] sys-fs/ddrescue-1.17-r1 USE="-static" 63 kB > > Total: 2 packages (2 new), Size of downloads: 158 kB > > What is the problem? He wants upstream to stop using lzip and instead use gzip or xz. To me that's an upstream request. Lars asked upstream and upstream said no with their rationale. Not much more to be done here by us.
(In reply to Doug Goldstein from comment #9) > He wants upstream to stop using lzip and instead use gzip or xz. Where did I say that upstream should stop using lzip? I have no problem with upstream distributing an lzip compressed tarball. However, they should offer distribute their software in some common format (like gzip or xz) _in_addition._
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(-)
