public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Problem with updating ddrescue addon
Date: Tue, 02 Feb 2021 14:17:10 +0000	[thread overview]
Message-ID: <43174D70-6B36-4F71-B4B2-633FEBDFA28D@ipfire.org> (raw)
In-Reply-To: <7a9be9b5-81bc-6b21-66bd-42c1f4ea063a@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

Hi,

Sorry for my late reply.

> On 31 Jan 2021, at 11:41, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hallo all,
> 
> 
> I saw that ddrescue addon was a version from 2010 so I thought it was about time to be updated. However since 2013 gnu has only been using lzip for the tarballs and stopped providing gzip versions.
> 
> IPFire does not have lzip available at the moment.
> 
> The options seem to me to be:-
> 
>     - remove ddrescue from the addon list

This is an option, since it does not seem to be the most popular add-on. On the other hand, it does not cause us any trouble, so I would vote for keeping it.

>     - leave ddrescue at the 2010 version - v1.12

That would be a bad choice, because we do not want to ship outdated software.

>     - update ddrescue to the last .gz tarball version in 2012 - v1.16

Again, this would be outdated.

>     - build lzip into the IPFire build system and update to latest ddrescue version from March 2020 - v1.25

I would vote for this. There is seems to be a lot of chaos with the compression algorithms right now. Gzip is outdated and does not compress very well, bzip2 is in the same situation. XZ compresses well, but it quite slow. LZMA was a stepping stone to XZ.

Now there is Zstandard, lzip and I have even seen tarballs being compressed with lzo. They all seem to be have their individual advantages and disadvantages, but ultimately we will have to use what the maintainers of upstream software chose to go with. Sooner or later we will have more packages using lzip.

>             should it go into the toolchain where the other compression packages seem to be (how to do that?)

Since we do not have anything in the toolchain stage yet that is requiring it, I would suggest building it as a normal package and do so as early as possible. It should not have any dependencies.

>             should it go into the build part of IPFire

Yes :)

> Looking through the changelog from v1.13 to 1.25 there are a lot of new options added but also some changes to the code itself that look to be fixing problems. I can't easily see how important these are. No changes have been marked as critical bug fixes or even marked as a bug fix.
> 
> My view would be to update to the latest version or remove ddrescue from the addons, as 11 years old seems a long time in computing terms.

Ancient :) Do we have more of those?

Thank you for looking into this. It looks like ddrecuse was a package that I simply have forgotten about.

> I am open to taking any guidance on the best approach for this.

Did I answer your questions?

Best,
-Michael

> 
> Regards,
> 
> Adolf.
> 


       reply	other threads:[~2021-02-02 14:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7a9be9b5-81bc-6b21-66bd-42c1f4ea063a@ipfire.org>
2021-02-02 14:17 ` Michael Tremer [this message]
2021-02-02 17:57   ` Adolf Belka
2021-02-02 18:55     ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43174D70-6B36-4F71-B4B2-633FEBDFA28D@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox