My fifth day with Haiku: let's port some programs
TL; DR : Beginner saw Haiku for the first time, trying to port some programs from the Linux world.
My first Haiku ported program packaged in its hpkg format
I recently discovered Haiku, an unexpectedly good PC operating system.
Today I will learn to transfer new programs to this OS. The main emphasis is a description of the first experience of switching to Haiku from the point of view of the developer for Linux. I apologize for the stupid mistakes made in the process, after all, since the first time I downloaded Haiku, not a week has passed.
I want to achieve three goals:
- Port a simple CLI application
- Port application from GUI to Qt
- Pack them later in hpkg format (since I'm still thinking about adapting AppDir and AppImage for Haiku ...)
Let's get started. In the documentation and development sections, as well as in the HaikuPorts wiki, I found the right direction. There is even an online PDF book BeOS: Porting a Unix application .
467 pages - and this is from 1997! Looking inside is scary, but I hope for the best. The developer’s words are encouraging: “for a long time, because BeOS was not POSIX-compatible,” but Haiku “for the most part” is already like that.
Porting a Simple CLI Application
The first thought was to port the avrdude application, but as it turned out, it had already been done a long time ago.
First attempt: nothing to watch
What I don’t understand is that for more than 10 years, applications have been ported to Haiku - despite the fact that the OS itself does not even have version 1.0.
Second attempt: need to rewrite
So, I will use the ptouch-770 , CLI to control the Brother P-Touch 770 printer, on which I print labels.
I print various labels on it, and you may have already seen it in a previous article. Earlier, I wrote a small wrapper program with a GUI in Python (since it is on Gtk +, I have to rewrite it, which is a good reason to learn a bit).
Label Printer Brother P-Touch 770. Will it work under Haiku?
Haiku's package manager knows about libraries and commands, so if I get the message “can't find libintl” when I run configure
, I simply run pkgman install devel:libintl
and the package I need will be found. Similar to pkgman install cmd:rsync
. Well, etc.
Except when this does not work:
/Haiku/home> git clone https://github.com/probonopd/ptouch-770 Cloning into 'ptouch-770'... remote: Enumerating objects: 134, done. remote: Total 134 (delta 0), reused 0 (delta 0), pack-reused 134 Receiving objects: 100% (134/134), 98.91 KiB | 637.00 KiB/s, done. Resolving deltas: 100% (71/71), done./Haiku/home> cd ptouch-770//Haiku/home/ptouch-770> make gcc -Wall -O2 -c -o ptouch-770-write.o ptouch-770-write.c ptouch-770-write.c:28:10: fatal error: libudev.h: No such file or directory #include <libudev.h> ^~~~~~~~~~~ compilation terminated. Makefile:16: recipe for target 'ptouch-770-write.o' failed make: *** [ptouch-770-write.o] Error 1/Haiku/home/ptouch-770> pkgman install devel:libudev 100% repochecksum-1 [65 bytes] Validating checksum for Haiku...done. 100% repochecksum-1 [64 bytes] Validating checksum for HaikuPorts...done. *** Failed to find a match for "devel:libudev": Name not found/Haiku/home/ptouch-770> pkgman install devel:udev 100% repochecksum-1 [65 bytes] Validating checksum for Haiku...done. 100% repochecksum-1 [64 bytes] Validating checksum for HaikuPorts...done. *** Failed to find a match for "devel:udev": Name not found
Perhaps udev is too full, so it does not exist for Haiku. Which means that you need to edit the source code I'm trying to compile.
Eh, you won’t jump above your head, and I don’t even know where to start.
Third attempt
It would be nice to have tmate
for Haiku, then I would let Haiku developers connect to my terminal session - in case something goes wrong. The instructions are quite simple:
./autogen.sh ./configure make make install
It looks good, so why not try it on Haiku?
/Haiku/home> git clone https://github.com/tmate-io/tmate/Haiku/home> cd tmate//Haiku/home/tmate> ./autogen.sh (...)/Haiku/home/tmate> ./configure (...) checking for libevent... no checking for library containing event_init... no configure: error: "libevent not found"/Haiku/home/tmate> pkgman install devel:libevent (...) The following changes will be made: in system: install package libevent21-2.1.8-2 from repository HaikuPorts install package libevent21_devel-2.1.8-2 from repository HaikuPorts Continue? [yes/no] (yes) : 100% libevent21-2.1.8-2-x86_64.hpkg [965.22 KiB] (...) [system] Done.checking for ncurses... no checking for library containing setupterm... no configure: error: "curses not found"/Haiku/home/tmate> pkgman install devel:libcurses (...) *** Failed to find a match for "devel:libcurses": Name not found/Haiku/home/tmate> pkgman install devel:curses (...) *** Failed to find a match for "devel:curses": Name not found
In this step, I open HaikuDepot and look for curses
.
Something was found, which gave me a hint for a more competent request:
/Haiku/home/tmate> pkgman install devel:libncurses (...) 100% ncurses6_devel-6.1-1-x86_64.hpkg [835.62 KiB] (...)./configure (...) checking for msgpack >= 1.1.0... no configure: error: "msgpack >= 1.1.0 not found"/Haiku/home/tmate> pkgman install devel:msgpack (...) *** Failed to find a match for "devel:msgpack": Name not found/Haiku/home/tmate> pkgman install devel:libmsgpack (...) *** Failed to find a match for "devel:libmsgpack": Name not found
Again went to HaikuDepot, and, of course, found devel:msgpack_c_cpp_devel
. What kind of weird names?
/Haiku/home/tmate> pkgman install devel:msgpack_c_cpp_devel 100% repochecksum-1 [65 bytes] Validating checksum for Haiku...done. 100% repochecksum-1 [64 bytes] Validating checksum for HaikuPorts...done. *** Failed to find a match for "devel:msgpack_c_cpp_devel": Name not found# Why is it not finding it? To hell with the "devel:".../Haiku/home/tmate> pkgman install msgpack_c_cpp_devel (...) The following changes will be made: in system: install package msgpack_c_cpp-3.1.1-1 from repository HaikuPorts install package msgpack_c_cpp_devel-3.1.1-1 from repository HaikuPorts Continue? [yes/no] (yes) : (...)/Haiku/home/tmate> ./configure (...) checking for libssh >= 0.8.4... no configure: error: "libssh >= 0.8.4 not found"/Haiku/home/tmate> pkgman install devel:libssh/Haiku/home/tmate> make (...) In file included from /boot/system/develop/headers/msgpack.h:22, from tmate.h:5, from cfg.c:29: /boot/system/develop/headers/msgpack/vrefbuffer.h:19:8: error: redefinition of struct iovec' struct iovec { ^~~~~ In file included from tmux.h:27, from cfg.c:28: /boot/system/develop/headers/posix/sys/uio.h:12:16: note: originally defined here typedef struct iovec { ^~~~~ Makefile:969: recipe for target 'cfg.o' failed make: *** [cfg.o] Error 1
At this step, I realized that porting a program to Haiku requires significantly more knowledge than you need for a simple rebuild.
I talked with friendly Haiku developers, it turned out that there is an error in msgpack, and after a few minutes I see a patch in HaikuPorts. I personally observe how a fixed package is built here (buildslave - virtual machines).
Build a fixed msgpack on buildmaster
In the meantime, send the patch to upstream to add Haiku support to msgpack .
Five minutes later, the updated msgpack is already available on Haiku:
/Haiku/home/tmate> pkgman update (...) The following changes will be made: in system: upgrade package msgpack_c_cpp-3.1.1-1 to 3.2.0-2 from repository HaikuPorts upgrade package msgpack_c_cpp_devel-3.1.1-1 to 3.2.0-2 from repository HaikuPorts Continue? [yes/no] (yes) : y 100% msgpack_c_cpp-3.2.0-2-x86_64.hpkg [13.43 KiB] (...) [system] Done.
Unexpectedly good. Did I say that ?!
Going back to the original task:
/Haiku/home/tmate> make (...) In file included from tmux.h:40, from tty.c:32: compat.h:266: warning: "AT_FDCWD" redefined #define AT_FDCWD -100 In file included from tty.c:25: /boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition #define AT_FDCWD (-1) /* CWD FD for the *at() functions */ tty.c: In function 'tty_init_termios': tty.c:278:48: error: 'IMAXBEL' undeclared (first use in this function); did you mean 'MAXLABEL'? tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP); ^~~~~~~ MAXLABEL tty.c:278:48: note: each undeclared identifier is reported only once for each function it appears in Makefile:969: recipe for target 'tty.o' failed make: *** [tty.o] Error 1
Now it seems msgpack is not guilty. Commenting IMAXLABEL
in tty.c
like this:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);
Result:
osdep-unknown.c: In function 'osdep_get_cwd': osdep-unknown.c:32:19: warning: unused parameter 'fd' [-Wunused-parameter] osdep_get_cwd(int fd) ~~~~^~ make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'. Stop.
Well, again ... By the way:
/Haiku/home/tmate> ./configure | grep -i OPENAT checking for openat... no
mr. waddlesplash tells where to dig:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd" (...)/Haiku/home/tmate> make (...) In file included from tmux.h:40, from window.c:31: compat.h:266: warning: "AT_FDCWD" redefined #define AT_FDCWD -100 In file included from window.c:22: /boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition #define AT_FDCWD (-1) /* CWD FD for the *at() functions */ make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'. Stop.
Here I laid out config.log .
They explained to me that there is something else to libresolv on Haiku in libnetwork. Most likely it is necessary to edit the code further. Need to think...
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} \;
The eternal question: what is happening.
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd" (...)/Haiku/home/tmate> make (...) # Success!# Let's run it:/Haiku/home/tmate> ./tmate runtime_loader: /boot/system/lib/libssh.so.4.7.2: Could not resolve symbol '__stack_chk_guard' resolve symbol "__stack_chk_guard" returned: -2147478780 runtime_loader: /boot/system/lib/libssh.so.4.7.2: Troubles relocating: Symbol not found
The same, only in profile. Googled and found it . If adding -lssp
"sometimes" helps, I try:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp" (...)/Haiku/home/tmate> make (...)/Haiku/home/tmate> ./tmate
Wow! It is starting! But...
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)
I'll try to debug the file here :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1
"Bad port ID" is already like a haiku business card. Maybe someone imagines what is wrong, and how to fix it? If anything, I will update the article. Link to GitHub .
Porting a GUI application to Qt.
I choose a simple QML application.
/> cd /Haiku/home//Haiku/home> git clone https://github.com/probonopd/QtQuickApp /Haiku/home/QtQuickApp> qmake . /Haiku/home/QtQuickApp> make /Haiku/home/QtQuickApp> ./QtQuickApp # Works!
Really simple. Less than a minute!
Packing applications in hpkg using haikuporter and haikuports.
Where to begin? There is no simple documentation, I go to the #haiku channel in irc.freenode.net and I hear:
- The
package
command is a low-level way to create packages. For the most part, PackageInfo is enough for it, as described in the section "Making it into a proper .hpkg package" - I need to do something like this
- You can use hpkg-creator (it crashes, error report )
It is not clear what to do. I suppose I need a beginner's guide in the style of "Hello World!", Ideally a video. It would be nice to have a convenient introduction to HaikuPorter, as done in GNU hello.
I read the following:
haikuporter
is a tool for creating shared batch projects for Haiku. It uses the HaikuPorts repository as the base for all packages. To create packages, haikuporter recipes are used.
Additionally, I find out that:
There is no need to keep recipes in the HaikuPorts vault. You can make another repository, put recipes in it, and then point haikuporter to it.
Just what I need - if you do not look for a way to publicly post the package. But this is a topic for another post.
Install haikuporter and haikuports
cd /boot/home/ git clone https://github.com/haikuports/haikuporter --depth=50 git clone https://github.com/haikuports/haikuports --depth=50 ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # make it runnable from anywhere cd haikuporter cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.conf
Writing a recipe
SUMMARY="Demo QtQuick application" DESCRIPTION="QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging" HOMEPAGE="https://github.com/probonopd/QtQuickApp" COPYRIGHT="None" LICENSE="MIT" REVISION="1" SOURCE_URI="https://github.com/probonopd/QtQuickApp.git" #PATCHES="" ARCHITECTURES="x86_64" PROVIDES=" QtQuickApp = $portVersion " REQUIRES=" haiku " BUILD_REQUIRES=" haiku_devel cmd:qmake "BUILD() { qmake . make $jobArgs }INSTALL() { make install }
Recipe Assembly
I QtQuickApp-1.0.recipe
file as QtQuickApp-1.0.recipe
, and then run aikuporter -S ./QuickApp-1.0.recipe
. Dependencies are checked for all packages in the haikuports repository, which takes some time. I'll go get some coffee.
And why should this check be done on my local machine, and not centrally on the server 1 time for everyone?
According to mr. waddlesplash:
With such that you can rewrite any file in the repository;) You can slightly optimize this by calculating the necessary information when necessary, because the latest changes are quite rare.
~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe Checking if any dependency-infos need to be updated ... Looking for stale dependency-infos ... Error: QtQuickApp not found in repository
It turns out that there is no ordinary recipe file that contains the source code of your application. You need to keep it in the repository in the HaikuPorts format.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/ ~/QtQuickApp> ../haikuport ~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
This fact makes assembly more cumbersome. I don’t really like it, but I think it is necessary so that, in the end, all open source software appears in HaikuPorts.
I get the following:
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe Checking if any dependency-infos need to be updated ... updating dependency infos of QtQuickApp-1.0 Looking for stale dependency-infos ... Error: QtQuickApp-1.0.recipe not found in tree.
What's wrong? After reading irc I do:
~/QtQuickApp> haikuporter -S QtQuickApp Checking if any dependency-infos need to be updated ... updating dependency infos of QtQuickApp-1.0 Looking for stale dependency-infos ... ---------------------------------------------------------------------- app-misc::QtQuickApp-1.0 /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe ----------------------------------------------------------------------Downloading: https://github.com/probonopd/QtQuickApp.git ... --2019-07-14 16:12:44-- https://github.com/probonopd/QtQuickApp.git Resolving github.com... 140.82.118.3 Connecting to github.com|140.82.118.3|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://github.com/probonopd/QtQuickApp [following] --2019-07-14 16:12:45-- https://github.com/probonopd/QtQuickApp Reusing existing connection to github.com:443. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git' 0K . 1.34M=0.06s 2019-07-14 16:12:45 (1.34 MB/s) - '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git' saved [90094] Validating checksum of QtQuickApp.git Warning: ----- CHECKSUM TEMPLATE ----- Warning: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c" Warning: ----------------------------- Error: No checksum found in recipe!
An interesting question arose. If I add a checksum to the recipe - will it match the latest git commit for continuous integration? (The developer confirms: "Nothing will come of it. Recipes are designed to be relatively stable.")
For fun, add to the recipe:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Still not happy:
~/QtQuickApp> haikuporter -S QtQuickApp Checking if any dependency-infos need to be updated ... updating dependency infos of QtQuickApp-1.0 Looking for stale dependency-infos ... ---------------------------------------------------------------------- app-misc::QtQuickApp-1.0 /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe ---------------------------------------------------------------------- Skipping download of source for QtQuickApp.git Validating checksum of QtQuickApp.git Unpacking source of QtQuickApp.git Error: Unrecognized archive type in file /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git
What is he doing? It's a git repository, the code is already there directly, there is nothing to unpack. From my point of view, the tool should be smart enough not to look for the unpacker if it is above the url with GitHub.
Maybe uri git: // will work
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"
Now it complains like this:
Downloading: git://github.com/probonopd/QtQuickApp.git ... Error: Downloading from unsafe sources is disabled in haikuports.conf!
Hmm, and why is everything so complicated, why can't you just “work”? In the end, it’s not so rare to build something with GitHub. Either the tools work immediately, without the need for customization, or as I call it "fuss."
Maybe it will work like this:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"
Nope. Still getting this dumb mistake and doing as described here
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.conf
I’m moving a bit further, but why is it yelling at me (GitHub is not safe!) And is still trying to unpack something.
According to mr. waddlesplash :
Well, yes, the reason was the desire to check the integrity of the data obtained for the assembly. One option is to verify the checksum of the archive, but you can, of course, also hash individual files, which will not be implemented, because it takes much longer. The consequence of this is the "insecurity" of git and other VCS. Most likely, this will always be the case, since creating an archive on GitHub is quite easy and often faster. Well, in the future, perhaps the error message will not be so flashy ... (we no longer merge such recipes in HaikuPorts).
~/QtQuickApp> haikuporter -S QtQuickApp Checking if any dependency-infos need to be updated ... Looking for stale dependency-infos ... ---------------------------------------------------------------------- app-misc::QtQuickApp-1.0 /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe ----------------------------------------------------------------------Downloading: git+https://github.com/probonopd/QtQuickApp.git ... Warning: UNSAFE SOURCES ARE BAD AND SHOULD NOT BE USED IN PRODUCTION Warning: PLEASE MOVE TO A STATIC ARCHIVE DOWNLOAD WITH CHECKSUM ASAP! Cloning into bare repository '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'... Unpacking source of QtQuickApp.git tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Cannot open: No such file or directory tar: Error is not recoverable: exiting now Command 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' returned non-zero exit status 2
As an old habit, I’m going to ask good people on the #haiku channel on the irc.freenode.net network. And where am I without them? After the prompt, I realized that I should use:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8" SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz" SOURCE_DIR="QtQuickApp-$srcGitRev" CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"
Well, it became clear what it was doing - it was downloading the archive with the sources of a certain revision. It is stupid, from my point of view, and not quite what I wanted, namely, to download the latest revision from the master branch.
One of the developers explained it this way:
We have our own CI, so everything that is placed in the haikuports repository will be secured for all users, and we do not want to risk collecting and delivering "all the latest version to upstream".
Got it! In any case, this happened:
waiting for build package QtQuickApp-1.0-1 to be activated waiting for build package QtQuickApp-1.0-1 to be activated waiting for build package QtQuickApp-1.0-1 to be activated waiting for build package QtQuickApp-1.0-1 to be activated waiting for build package QtQuickApp-1.0-1 to be activated (...)
It repeats this ad infinitum. Apparently, this is a mistake (is there an application? I did not find it).
With haikuporter
and the haikuports repository you don’t feel the level “just works”, but as a developer, I like some things about working with Haiku. For the most part, this is similar to the Open Build Service - a set of tools for building Linux assemblies: extremely powerful, with a systematic approach, but superfluous for my small hello world application.
Again, according to mr. waddlesplash:
Indeed, HaikuPorter is very strict by default (plus there are lint mode, as well as strict mode, making it even more strict!), But only because it creates packages that will work, and not just create packages. Therefore, he swears on undeclared dependencies, libraries not imported properly, incorrect versions, etc. The goal is to catch all problems without exception, including future ones, before the user finds out about this (therefore, it was not possible to install avrdude, because the dependency was actually indicated in the recipe). Libraries are not just separate packages or even undefined versions of SO. HaikuPorter ensures that all of this is maintained in the recipes to avoid runtime errors.
In principle, this level of rigor is justified when creating the operating system, but it seems to me unnecessary for the hello world application. I decided to try something else.
Building applications in hpkg format using the "package create" command
Maybe this simple instruction will suit me better?
mkdir -p apps/ cp QtQuickApp apps/cat > .PackageInfo <<\EOF name QtQuickApp version 1.0-1 architecture x86_64 summary "Demo QtQuick application" description "QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging" packager "probono" vendor "probono" copyrights "probono" licenses "MIT" provides { QtQuickApp = 1.0-1 }requires { qt5 } EOFpackage create -b QtQuickApp.hpkg package add QtQuickApp.hpkg apps# See below if you also want the application # to appear in the menu
Unexpectedly fast, unexpectedly simple, unexpectedly effective. Just the way I like it, amazing!
Installation - what and where?
Moved the QtQuickApp.hpkg file to ~/config/packages
using the file manager, after which QtQuickApp magically appeared in ~/config/apps
.
Again, unexpectedly fast, simple and effective. Amazing, incredible!
But ... (where without them!)
The application is still not in the application menu list and in QuickLaunch. I think I already know how to fix it. In the file manager, I move QtQuickApp.hpkg from ~ / config / packages to / system / packages.
Nah, still missing. Apparently, I (well, the instruction) missed something.
Having looked at the "Contents" tab in HaikuDepot for some other applications, I saw that there are files like /data/mimedb/application/x-vnd...
what is even more remarkable, /data/deskbar/menu/Applications/…
Well, and what should I put there? Well ...
mkdir -p data/deskbar/menu/Applications/ ( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . ) package add QtQuickApp.hpkg apps data
I am quite sure that this trick will give a ride, but questions remained: why is it needed, what is it for? In my opinion, this destroys the general impression that the system is so sophisticated.
As explained by mr. waddlesplash:
Sometimes there are applications that other applications need, but not on the menu. For example, the LegacyPackageInstaller in your screenshot that processes .pkg archives in BeOS format. I want users to set them, but their presence in the menu will lead to confusion.
For some reason, it seems to me that there is a simpler solution, for example Hidden=true
in Linux .desktop
files. Why not make the “hidden” information a resource and an attribute of the file system?
What is not particularly sophisticated is the name of a (certain) application that displays the menu, deskbar
, is tightly bound in the path.
mr. waddlesplash on this occasion explains:
"Deskbar" in this case should be understood as a kind of general term (approximately the same as "taskbar", referring to both the Windows application and the general concept). Well, since this is adeskbar
, not a "Deskbar", this can also be understood in a similar way.
2 "almost identical" directories with applications in them
Why are there 2 directories with applications, and also why is there one in my QtQuickApplication and not in the other? (After all, this is not one system, but the second user, which I personally would understand).
I am really confused and I think that we should unify this.
comment mr. waddlesplash
In the Apps directory there are applications that are not needed in the menu. But the situation with the menu really needs to be improved, to make it more customizable.
Application, or this will not happen;)
I thought: is it so necessary to place applications in /system/apps
, if users see them there - it is undesirable. Maybe it's better to place them in another place where the user will not encounter them? Just like it was done on Mac OS X, where the contents of the .app
packages, which should not be visible to the user in /Applications
, are hidden in the bowels of / System / Library / ... ``.
What about dependencies?
I think it's worth pointing out dependencies somehow, right? Can Qt be considered a mandatory part of the default Haiku installation? Nope! Qt is not installed by default. Can a package build program automatically detect dependencies by checking ELF files? I was told that HaikuPorter really does, but package
does not. That's because he is just a "package hpkg
", which in itself simply creates hpkg
files.
Should Haiku be more refined by adding a policy according to which a package should not have dependencies on packages not included in haikuports
? (I would like so much, since such a policy makes the task much easier - the system would be able to automatically resolve the dependencies of each package downloaded from anywhere without fussing with additional package sources).
mr. waddlesplash explains:
, , ( ) — .
-, haikuports, . , , . [ AppImage? — . ]
? , , .
?
, Inkscape (, , Haiku, ). https://gitlab.com/inkscape/inkscape
.
, - , , , , , AppImage Linux ( , , , [ ! — . ] ). , , , , .
( )
Docker. GitLab runners Linux, , runners (, , Haiku, , , Docker , FreeBSD Docker, Haiku).
Haiku Docker Linux. Haiku . ? Haiku Docker, - QEMU/KVM ( , Docker)? , . , Scribus — Haiku. , , Haiku.
:
, , CMake/CPack. , , , . : , haikuporter , , , . Linux (Haiku ).
. Linux (, ..), , . , Haiku Linux — .
Conclusion
POSIX Haiku , , . , #haiku irc.freenode.net. , .
, Qt, — . .
, " ", .. , haikuports. ( ) GitHub . Haiku Linux, Mc, "" XCode .app
, .dmg
, .
"" , , Linux, , , Haiku , .
! Haiku DVD USB, . Etcher
? telegram- .
: C C++. Haiku OS Recipe Collection
All Articles