Using PaDS in 64-bit Systems (Optionally any Puppy)

[mikeslr]

Hi All,

Edit: The problem discussed in this post is avoided by using the new version of PaDS RSH (now known as ITSMERSH) has published. See this thread: http://www.murga-linux.com/puppy/viewto ... 922#998922

PaDS, as you may know, is a utility for combining a bunch of pets, debs, and other packages into one SFS. It's one of the superb tools created by Lazy Puppy, the artist formerly known as RSH . You can find out about it, how to use it, and obtain it here: http://murga-linux.com/puppy/viewtopic.php?t=81511. Be sure to find out about using the right-click "combine to sfs" on folders containing all source files.

Under 32-bit operating systems it worked flawlessly, and was my "go-to" application for packaging Ubuntu applications for use under Puppies. Sometimes, with dependencies, scores of debs would have to be combined. IIRC, in one instance 84 debs were involved.

Unfortunately, my experience was that it didn't function under 64-bit systems. SFSes were created under 64-bit systems, but they were devoid of contents.The problem, as far as I could tell, was not PaDS, itself, but rather the associated application, unrpm.pet, required to unpack "debs". Unrpm uses a binary at /root/my-application/bin named dpkg-deb2. It was compiled in 2008.

So with that clue, I wondered if substituting a modern equivalent would solve the problem. I was working in Xenialpup64 which has dpkg-deb located at /usr/bin. So what I did was delete the dpkg-deb2 binary at /root/my-applications/bin and substitute in its place a symbolic link (edit: see below) to /usr/bin/dpkg-deb, repackaging the the modified unrpm as a pet named unrpm-64bit.

Although the pet was built in Xenialpup64, it did work under Tahrpup64 and should work under LxPuptahr64. Under Tahrpup64 PaDS using unrpm-64bit was used to successfully construct an Imagination SFS.

Situations involving Slackware packages and rpms? Your guess is probably better than mine. Slacko64-6.3.2 does include /usr/bin/dpkg-deb, so unrpm64 should be able to decompress debs under that Slacko.

Edit, 8 April 2018: If you are looking for the unrpm-64bit.pet, use the attached unrpm-all.pet. Rather than a symlink, it uses a bash-script to call /usr/bin/dpkg-deb. But the primary reason for the change is to make it clear that it can be used with any Puppy without concern for that Puppy's architecture.

Do not install unrpm.pet after installing unrpm-all.pet. unrpm.pet will overwrite unrpm-all.pet's bash-script, preventing its functionality in 64-bit systems.

Let me know if it works or has problems under other Puppies.

mikesLr

[slavvo67]

What are you trying to accomplish? I have 2 utilities the combine a directory of debs or a directory of pets. Work in 64 or 32 bit.


Slavvo67

Edit: Forget it. I should learn to read....

[mikeslr]

Hi slavvo67,

What other utilities do you have which work under 64-bit systems to combine packages --debs, txzs or others?

mikesLr

[slavvo67]

Just some scripts with GUI using YAD on top. I'll provide links but traveling so it'll be a few days before I get them uploaded.

[mikeslr]

Hi all,

Since my first post, I've had occasion to build applications under several recent Puppies, both 32 and 64 bit. Gradually it occurred to me that since XenialPups and Tahrpups (both 32 and 64 bit) and pupjibaro jessie synaptic* by josejp2424had been devised to decompress debs, perhaps the binary they employed to do so bore the same name and was located in the same place. It was: /usr/bin/dpkg-deb.

So the attached pet substitutes for unrpm's binary named dpkg-deb2 a script named dpkg-deb2 which invokes the binary /usr/bin/dpkg-deb without regard for whether that binary is 32 or 64-bit.

Edit Feb 1,2017: As the following Puppies all have /usr/bin/dpkg-deb, it should work in all Ubuntu, debian and Slackware based Puppies, Saluki/Carolina, FatDog, Lighthouse and the DebianDogs. The later, however, have their own tools for this purpose. I have not yet examined Fatdog64-7x. Currently, only tested under Tahrpups(32&64), & Xenialpups(32&64).

Repeating instructions, just in case you've skipped down: Install PaDS, install unrpm-all. Do not install the unrpm pet found on the PaDS thread.

In the past, I used PaDS under 32-bit Pups to build 64-bit applications for use in 64-bit Pups. So, PaDS with unrpm-all should work for that purpose. But, I've never tried to build 32-bit applications under a 64-bit OS with 32-bit libraries installed/loaded . Whether it, or Lazy Puppy's original unrpm, will function in that environment for that purpose remains questionable.

Feedback is still welcomed.

mikesLr

* josephjp2424's pupjibaro jessie synaptic can install both debs and pets, and use SFSes. You can find out more about it and the link to its ISO here: http://murga-linux.com/puppy/viewtopic. ... 724#940724. Installing pets, however, could interfere with synaptics ability to accurately determine what has already been installed and so, what files were actually necessary from repos. When possible, the use of SFSes --as they do not install-- would be preferable.

Additionally, some time ago I had employed synaptic under Jejy69's LxPup-aptget-test to download, but not install, all debs necessary for an application, and then used those debs to build the application of Lupu. IIRC, when synaptic is set to "download but not install", debs are downloaded into a temporary folder in /var. I recall having to move them before I shutdown LxPup-aptget-test.

While exploring pupjibaro jessie synaptic, I recalled the above which motivated my reconsideration of unrpm in the hope that PaDS could be used under it.

[mikeslr]

Hi all,

unrpm-all.pet used with PaDS continues to work fine from a newly setup Puppy, or pfix=ram with PPM configured and just unrpm-all.pet & PaDS installed.

But, from my "fully stocked Puppies" something goes wrong. The SFS created includes the /root directory with an empty folder having the name of the application I attempted to build.

As unrpm uses the same dkpg-deb as UExtract, and UExtract works fine, something I installed must be interfering with the logic of PaDS's scripts. Don't know what. Easier to just boot pfix=ram etc. If & when I have a chance I'll work thru what I've installed or SFS-loaded that interfering.

mikesLr

[LazY Puppy]

Just don't create the folder you want to build the sfs from in /root !!!

[mikeslr]

Just don't create the folder you want to build the sfs from in /root !!!

Hi LazY Puppy,

I didn't. To be specific, the folder holding the debs was, for example, in /mnt/dev_save/my-stuff/temp/my_new_app-1: my_new_app being specific to the new app I was building, with -1 actually referring to the version of that app's primary binary; or some descriptive name, such as K_Office_libs, whose pet is now stored in my Xenialpup32 folder in /mnt/home/Pup-Vault.

To be even more specific, in order to run the 47 mb K-Office kiramm recently provided a link to in Xenialpup, several debs have to be installed into xenialpup. [Alternatively, the K-Office.sfs would have had to be rebuilt to include the files from those debs, or the debs, themselves installed each time I wanted to have a different installation of Xenialpup use K-Office]. The easiest way to end up with a Pet from multiple debs is to first build an SFS using PaDS, mount that SFS, copy its files to a directory and dir2pet that directory.

That worked from a "nearly virgin" Xenialpup. But from my "fully fleshed out with the Out house sink" Xenialpup, something went wrong. Which is why I suspect that some application I installed interferes with PaDS, itself.

And I thought it appropriate to advise users of PaDS who may run into a similar problem that the problem was not with PaDS but with a conflict between PaDS and some unknown application. At least, that's my guess.

mikesLr

[mikeslr]

Hi All,

See the following post regarding a problem when creating SFSes for Puppies based on Ubuntu binaries, such as Xenialpup64 and Tahrpup64, and my current "Work-Around": http://www.murga-linux.com/puppy/viewto ... 945#960945

mikesLr

P.S. It is possible that the problem I mentioned here, http://www.murga-linux.com/puppy/viewto ... 542#943542 was just a result of my having done something stupid: without thinking after creating a WorkFolder into which the contents of an SFS were copied, running 'combined to SFS' rather than dir2sfs. Since the cited post, I've done that twice.