From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Problem with updating ddrescue addon Date: Tue, 02 Feb 2021 18:57:52 +0100 Message-ID: <83faf7d8-be9b-3b65-7199-420ffdd16369@ipfire.org> In-Reply-To: <43174D70-6B36-4F71-B4B2-633FEBDFA28D@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3479340939296785727==" List-Id: --===============3479340939296785727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 02/02/2021 15:17, Michael Tremer wrote: > Hi, >=20 > Sorry for my late reply. No problems. I know all you guys are busy and will reply when you are able to. >=20 >> On 31 Jan 2021, at 11:41, Adolf Belka wrote: >> >> Hallo all, >> >> >> I saw that ddrescue addon was a version from 2010 so I thought it was abou= t 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 >=20 > 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 keepin= g it. >=20 >> - leave ddrescue at the 2010 version - v1.12 >=20 > That would be a bad choice, because we do not want to ship outdated softwar= e. >=20 >> - update ddrescue to the last .gz tarball version in 2012 - v1.16 >=20 > Again, this would be outdated. >=20 >> - build lzip into the IPFire build system and update to latest ddresc= ue version from March 2020 - v1.25 >=20 > I would vote for this. There is seems to be a lot of chaos with the compres= sion 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 w= as a stepping stone to XZ. Good. Will work on it. >=20 > 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 disadvant= ages, but ultimately we will have to use what the maintainers of upstream sof= tware chose to go with. Sooner or later we will have more packages using lzip. >=20 >> should it go into the toolchain where the other compression p= ackages seem to be (how to do that?) >=20 > 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 pos= sible. It should not have any dependencies. Clear. >=20 >> should it go into the build part of IPFire >=20 > Yes :) Clear. >=20 >> Looking through the changelog from v1.13 to 1.25 there are a lot of new op= tions added but also some changes to the code itself that look to be fixing p= roblems. I can't easily see how important these are. No changes have been mar= ked 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 t= he addons, as 11 years old seems a long time in computing terms. >=20 > Ancient :) Do we have more of those? Yes there are others and as I find them I am looking at updating them. >=20 > Thank you for looking into this. It looks like ddrecuse was a package that = I simply have forgotten about. >=20 >> I am open to taking any guidance on the best approach for this. >=20 > Did I answer your questions? Absolutely yes. :) Regards, Adolf. >=20 > Best, > -Michael >=20 >> >> Regards, >> >> Adolf. >> >=20 --===============3479340939296785727==--