Questions to FAQ about TCL

[TinyCoreLinux]

Hello, my friends! I have some simple questions for you here.These are easy questions for you, But it is very difficult for a noob like me who is full of curiosity, and I think these questions are meaningful. I also hope to get your help here, and of course I will share these questions with my friends and others. Thank you all !
Note: In order to save the resources of the server and make it easy to browse, All questions will be posted in the form of comments. Again, I hope you can understand.

[TinyCoreLinux]

Q1: How do I convert *.deb or *.rpm to *.tcz? And how to solve the dependency problem？
I try to install and run chrome.rpm on TCP64/TCL. There have been some problems when I switch to the first to "/opt/Google/chrome/" directory and enter ". / chrome " running chrome, but tell me linss3.so and libcups are doesn't exist respectively. then I install and load the nss.tcz and libcups.tcz and input again ". /chrome" tried to run again but this time tell "chrome" doesn't exist, why the :chrome" file already exists, but tell me it doesn't exist?why?why?why?
I firmly believe that this is definitely not an environment variable issue, much less a permission issue or directory error, and that "chrome" is an executable, if it is not, it will not at least tell me that the library file is missing and report an error!

I know there's Chromium and Firefox in the repo and I've already used them, But I still want to know the solution to my question.

[Juanito]

Is it looking for bash or perl or python?

[andyj]

Have you checked this thread? http://forum.tinycorelinux.net/index.php/topic,23768.0.html

[GNUser]

As juanito pointed out, some applications use a launcher script (e.g., a bash, perl, or python script). Perhaps chrome is like that. If the interpreter for the application's launcher script is not present on your system, you'll get a confusing error like the one you're getting (i.e., an error that says "foo does not exist" when foo clearly exists).

Another cause for this kind of error is a binary (ELF file) with wrong path to the system's linker. TCL64 keeps the linker in  /lib  (specifically, /lib/ld-2.30.so and its symlink /lib/ld-linux-x86-64.so.2) while in non-TCL 64-bit distros the linker is usually in /lib64.

These two commands should solve your problem:

Code: [Select]

$ tce-load -wi bash
$ sudo ln -s /lib /lib64
If still no luck, install some more interpreters:

Code: [Select]

$ tce-load -wi perl5 python3.6

[TinyCoreLinux]

@juanito @andyj  @GNUser
It seems that you do not understand me, it is true that my English is too poor, well, it is my fault. You can directly follow my steps below and maybe you can understand me.

Code: [Select]

wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
rpm -i  google-chrome-stable_current_x86_64.rpm
cd /opt/google/chrome
./chrome // run chrome

And I'm not referring specifically to Chrome, I'm just using Chrome as a metaphor to illustrate my problem.

[Juanito]

load dbus and start the dbus daemon and then:

Code: [Select]

$ sudo ln -s /usr/local/etc/fonts /etc
$ sudo ln -s /var/lib/dbus/machine-id /etc
$ cd /opt/google/chrome
$ dbus-run-session ./chrome // run chrome

[TinyCoreLinux]

The second time I used the Chrome.deb file to illustrate my problem, you can just watch me do it, TCL/CP64 doesn't offer a DPKG package manager, so I had to install it manually.

Code: [Select]

wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.deb
ar vx chrome-stable_current_x86_64.deb
tar -xzvf data.tar.gz
find / -name control // The control file for the *.deb
                                   //  package cannot be found in the
                                  //  unzipped file.
cd .../google/chromw
./chrome // run chrome


[Juanito]

Chrome ran using the commands I gave above.

The main point here is that tinycore does not use deb/rpm packages - you might be able to get them to work, but it will rely on some troubleshooting on your part.

[TinyCoreLinux]

If I want to implement what I'm talking about (that is, transformations between packages or compatibility issues between different package managers), what should I do about the dependency aspect? Besides, you only said that chrome is the case, what if there is another *.deb or *.rmp to tcz.dep conversion? What is the essential difference between packages? It is very important for me to solve this problem, because it affects not only the individual but also the development of a new product or software. I hope to get some help or advice from you, thank you again.

[andyj]

Code: [Select]

$ dbus-run-session $(which google-chrome)
So this is the dbus trick to get chrome to run! I still get lots of errors but it does appear to work.

@NOOB, the essential difference between packages is the metadata, which may include dependencies, a description, version info, and such. The rest of the package will be a tar or cpio archive of the application files, compiled for the target distribution using the target's libraries. This is where you will find the incompatibilities, as rarely are two distributions sync'ed up on library versions. It is not a goal of TC or any other distribution that I know of to be in sync with all the rest. If a foreign package works, then you are lucky. If not, complaining here won't help any more than going to Ubuntu, Fedora, Slackware, or anyone else's forum and complaining to them that some foreign package doesn't work.

[Rich]

Hi NOOB
You will need to learn about the format of a  .tcz  extension by unpacking it an examining it:

Code: [Select]

tce-load -w -i squashfs-tools submitqc
mkdir TestArea
cd TestArea
wget http://tinycorelinux.net/11.x/x86_64/tcz/geany.tcz
unsquashfs -d Geany
Now take a look through the  Geany  directory.
You'll see everything (bin, lib, share) is installed under  usr/local.  That's where packages are compiled to install for Tinycore.
usr/local  is also where a program may expect to find things.

If the deb or rpm you are trying to convert expects to be in usr, you may have to place it under  usr  and add links to  usr/local.

Look at:

Code: [Select]

Geany/usr/local/tce.installed/geanyThat contains commands to run after the extension is installed. Notice the file name is identical to the extension name. If it's
not identical, it will not get run.

If you want an icon you will need a  .desktop  file:

Code: [Select]

Geany/usr/local/share/applications/geany.desktopThis one is for  geany  but it shows you the format. Not all extensions provide all of the fields in that file. Once again, the file name is
identical to the extension name.

To create a new  .tcz  file:

Code: [Select]

mksquashfs Geany/ SomeFileName.tcz -noappend
You can check your extension for problems by running this command in the directory containing any extensions you wish to check:

Code: [Select]

submitqc --libs 2>&1 > submitqc.txtThen check the results in  submitqc.txt

[GNUser]

NOOB, getting the same binary to work across different distros can be anywhere from trivial to highly complex (that's why such things as AppImage, Flatpak, Snap, and Nix package manager exist). For bigger applications such as web browsers, the complexity is such that you'd be better off using a cross-distro format such as AppImage than trying to "convert" .deb to .tcz.

By the way, even if two distros are compatible at the level of libraries and glibc, such a simple thing as package names can totally wreck the kind of conversion you're talking about. For example, if a .deb says that it needs "python3", that's not going to translate well because on TCL the package is actually called "python3.6" while on other distros it's simply called "python". Same thing with "openssl" (on TCL64 the package is called "openssl-1.1.1"), among countless other examples.

The bottomline is that each distro is best used on its own terms. TCL was made to work with .tcz extensions. Even supposedly cross-distro formats as AppImage are not always trouble-free Once you're talking about a frankly alien format (such as .deb or .rpm on TCL), then you'd better know what you're doing and have lots of free time.

P.S. To get the most of TCL (including understanding its own ingenious and minimalistic approach to packaging), read this book: http://www.tinycorelinux.net/corebook.pdf

[PDP-8]

I'm running a big risk making this statement knowing it could be my last depending on how it is viewed, but I have to be brutally frank in what I see:

1) The recent rash of "noobs" who immediately want to push the adoption of other package formats is merely a political one, not a technical issue!

2) What some desire is to "free" TinyCore from the TCZ format.  Not because of anything technical, but because of the submission/approval process of those in charge of the project.

3) This was revealed earlier by another noob, who went on an anti-tc rant, clearly stating that he despised the control group of tcz's and pines for the days of DSL desktops. Hey, at least he was honest and stated his purpose right off the bat!

4) Rather than fork TC to support a different packaging format / management personnel, the discussions are a way to either make US do the work for a possible fork for them, or somehow try to convince the community that being able to run ANY package without any oversight by a technical organization is good for our soul.

The red-flags about noobs with this agenda:

Proclaiming I'm just starting out with Linux, so be gentle.  Yet can quickly recite all the package formats with proper spellings, or * shortcuts.

Unwillingness to use an installer, but immediately to to avoid tcz's, and just download "parts".  When those manually downloaded parts - which also have dependencies dont work - we are called upon ways to fix it without resorting to tcz packages.

Real noobs usually don't have a problem learning TC first using tcz's.  Those that do, and insist on doing it the hard way with endless threads that go nowhere, may not have TC's best interest at heart.

Sorry - had to get that off my chest.  All it is with this agenda is about not liking tcz's and specifically because there is project management with the ultimate say of what goes in, and what does not.

And my apologies to real noobs to TC.

[PDP-8]

This has not gone unnoticed either ..

Sadly, John Murga of Murga-Linux has passed away.  R.I.P. John.

http://blog.puppylinux.com/vale-john-de-murga

With the support forum down, there may be void for who knows how long.  Fortunately, Puppy-Linux might be better able to pick up that slack, and might be a better substitute for the "all package format" support to gain some traction.