rolandradio wrote: ↑Mon May 02, 2022 8:44 pm
...
Thanks for the link, I never converting a Tarball and have to dig in for it to understand, or is it not so difficult as it is ?
A tar.bz2 must be compiled for the type of CPU and the type of Operating system right ?
Example : Slacko, Racy, Tahr, Xenial are not compatible each other, and the tarball has to be compiled for one of these to work.
That's why I searching for Pet files for Slacko 6, easier to install.
But I shall read and try ..........
No. A 'tarball' such as tar.gz or tar.bz is just a package which has been compressed. Other examples of packages which have been compressed are zip, pzip, 7zip and rar. Compressing packages is a way to conserve storage space and band-width.
Only two things matter to the User who has obtained a compressed package:
(1) Does the system have an application to decompress it? That's why you'll often find advise on this forum to use UExtract. viewtopic.php?p=3263#p3263 jakeSFR has developed an Extractor which is all-but Universal [check that link for the extensive list of file-types it can decompress] and is 'no-arch'. The latter means that it will function under almost all Puppies.
(2) Will the decompressed package work with your Puppy? Although all Puppys are different, they are not 'all that different'. A package consists of files, folders and sub-folders --the latter two holding other files and maybe folders-- all structured consistent with long established rules for where certain type of files belong. See this post, viewtopic.php?p=584#p584 and bigpup's reply immediately after it for what that structure looks like.
Until the advent of 64-bit Linux operating systems the structure of all Puppys was identical. Puppys, however, are primarily 'woofed'/built to be binary compatible to Slackware, debian or Ubuntu. That enables such Puppys to use almost OOTB the applications from their respective 'binary-compatible' distro, direct from the repository maintained by that binary-compatible distro.
Slackware decided to place 64-bit libraries in folders having names different from those used by debian/Ubuntu for 64-bit libraries [or vice-versa: I don't know which came first]. Consequently, while in most cases packages for 64-bit 'Ubuntu' puppys will work in 64-bit 'debian' Puppys and vice-versa and these can often use the files contained in 64-bit Slackware packages, to make use of such 'Slacko' files the package would have to be restructured so that the files will be located where a debian/ubuntu expects to find them. And the same condition applies to using 64-bit debian/ubuntu packages in a Slacko.
This near-universality breaks down in three ways. The 32-bit/64-bit architectural difference. The second is that Puppys substitute light-weight 'infra-structure', often 'bash-scripts, for the heavier weight infra-structure used by the 'binary-compatible' distros. So an application direct from the binary-distro's repo might not run in a Puppy until you also install the 'infra-structure' that distro expects. The third is that the files which constitute Slackware's 'infra-structure' may be different from debian/ubuntu.
The only applications which ABSOLUTELY depend on how they are compiled are the drivers of hardware. And that doesn't depend on what distro is involved. Rather it depends on what Kernel=vmlinuz is used. A Hugh-Kernel package (vmlinuz + drivers compiled for it) published for Slacko can be 'swapped' into a 'Ubuntu' and vice-versa. See rockedge's post on how Puppys' Work, viewtopic.php?p=55827#p55827
Taking advantage of the almost Universal structure among Linux distros, independent publishers such as LibreOffice and Mozilla create products which can be used OOTB under most distros. firefox is such a publication. Moreover for as far back as I've been using Mozilla web-browsers they have been packaged essentially as portable. You can locate the folder containing all the firefox files in /opt/, in /usr/lib or on /mnt/home/somewhere or anywhere else. All that is then optionally needed to run firefox is (a) an executable script 'on the path'; a pixmap to be displayed on the Menu; and a 'desktop' file in /usr/share/applications which identifies the pixmap, calls the executable script and is used by your system to generate a Menu entry. The other options are to just file-browse to the firefox binary and left-click it. Or drag the binary to the desktop which, like Windows, creates a 'short-cut'.
It is rare that an application is 'compiled' for any Puppy. They can be. But, more often if an application is available from a Puppys 'binary-compatible' distro what appears as a pet or SFS has merely been to download the application and all its dependencies -including those not built-into a Puppy-- from the binary-compatible's repo and package it as a pet or SFS. If the application was published by an independent, its simply been repackaged to make it easy to install as pet or use as an SFS or, as MikeWalsh and fredx181 do, as a portable or AppImage.
Of course, for firefox to function your system has to provide the libraries the publisher of firefox expects an operating system to have. Those expectations increased over time. The gist of my prior post was to point you to the post which identified the then required libraries and provided links where you could find them. Hopefully, the above will explain why the libgtk-3-0_3.4.2_i386_precise.pet --whose name reveals that it was originally constructed to be used under precise-puppy-- can be used in a 32-bit Slacko.
