Needed - someone to create an 'ar' pet....

[mikeslr]

As MIkeWalsh explains here, viewtopic.php?p=43806#p43806
"Debian are in the process of changing .debs over to a new compression standard. The installed Puppy 'dpkg-deb' is built to work with the old standard, and no longer works with the new one. Extraction techniques for .deb packages, all across the web, recommend 'ar' as the first thing to try.

Now; Puppy has access to the 'ar' utility, but you don't install it from the PPM or a .pet package. It's part of 'binutils', which in turn is part of the devX SFS package that comes with every Pup. So the way to get access to the 'ar' utility is to load your devX first....."

If Mike's right, that's an inconvenient way to go about the not infrequent task of making use of a debian deb. I would think that a couple of small pets (maybe only one) would return recent Ubuntu and debian binary-compatible Puppys to their respective former 'binary-compatible' status.

[mikewalsh]

@mikeslr :-

In my case, Mike, because I have so much RAM to play with - three parts of which rarely gets used - I tend to keep the devX loaded all the time. With my resources, it's barely noticed.

As soon as we know for definite that the new compression standard is in general use across the board, it'll be easy enough to build a .pet for both 'ar' AND 'dpkg-deb' from the respective repos.....though this may not be possible with older Pups like Xenial and Tahr. If I can find the source code, I may have a go at building them myself.

T'other Mike.

[mikewalsh]

@mikeslr :-

Okay. Now then:-

What I've built here are .pet packages that will install the 'ar' utility (+ dependencies) into each of the main successive 'flagship' releases.....Tahr64, Xenial64, Bionic64 & Fossa64. This is all that's needed for the Chrome/Iron-portable 'updater' to work, and will obviate the need to load the devX in order for the updater to function & do its job.

Dpkg-deb is going to be a whole 'nother ball game. There's a suite of something like a dozen or more utilities, all part of the same source code package. Before these can be compiled, you need to compile an up-to-date version of Perl. And before THAT can be compiled, there's a couple of other items also need to be replaced with brand-new, compiled, up-to-date versions.....

As if that wasn't enough to be going on with, older Pups like Tahr & Xenial are going to be out of luck anyway.....because their GCC compilers are simply too old. It's not going to be possible with these Puppy's native tool-chains, so the only way I can see around this is for someone with the necessary skills to statically compile them for these older Pups. And that's way out of my league, I'm afraid.

Compiling is not my strong point. TBH, my compiling skills are crap.....so I'll have to bow out of that one, and leave it to those who know what they're doing. The 'ar' packages were simply lifted straight from the devX; if anybody wants them, you can find 'em here, at my MediaFire a/c:-

https://www.mediafire.com/folder/x32vx2 ... '+packages

Hope they're useful for some of you!

Mike.

[amethyst]

Can UExtract extract this?

[mikewalsh]

Can UExtract extract this?

Um.....extract what, exactly?

'Ar' & 'dpkg-deb' are both back-end utilities used by UExtract (amongst many, many others). If neither was present on the system, UExtract would not be able to extract a .deb package.....at least, that's what I understand.

UExtract usually tries 'ar' before 'dpkg-deb'.

'Ar' is needed by the updater script I've built for the Chrome & Iron portables. These .pets were built primarily to avoid having to load the devX, since that's where 'ar' lives. Don't forget, UExtract is basically a front-end for many backend utilities...

Mike.

[amethyst]

The .deb package that use that archiving algorithm.

[mikewalsh]

The .deb package that use that archiving algorithm.

UExtract will be able to extract any .debs that still use the older compression algorithm. Whether an updated version of dpkg-deb will then be able to work with both old AND new, I wouldn't like to say. It's possible we may need to have two different versions on the system....

I just don't know, Nic. It's still too early to say.

Mike.

[amethyst]

The .deb package that use that archiving algorithm.

UExtract will be able to extract any .debs that still use the older compression algorithm. Whether an updated version of dpkg-deb will then be able to work with both old AND new, I wouldn't like to say. It's possible we may need to have two different versions on the system....

I just don't know, Nic. It's still too early to say.

Mike.

I just wanted to know whether the current version of UExtract already has the ability to extract that sort of .deb package because if it did one could repackage the contents to ones needs. But apparently not.

[JakeSFR]

Ok, are we talking about Zstandard here? That's the only, recent transition in DEB world (and not only) that I'm aware of.
If so, then the answer is a resounding "yes" - UExtract can extract zstd compressed DEB packages (since v3.42, 08 Feb 2020), provided that both ar and zstd utilities are installed.
Or dpkg-deb from dpkg that supports it (the latest does).

Greetings!

[mikewalsh]

@JakeSFR :-

Thanks for clarifying, Jake! That's much appreciated, mate.

I can't think of anyone better qualified to comment on this one.....

Mike.