TL; DR: Un novato vio Haiku por primera vez, intentando portar algunos programas del mundo Linux.
Mi primer programa portado de Haiku, empaquetado en formato hpkg
Descubrí Haiku, un sistema operativo sorprendentemente bueno para PC.
Hoy aprenderé cómo portar nuevos programas a este sistema operativo. El enfoque principal es una descripción de la primera experiencia de cambiar a Haiku desde el punto de vista de un desarrollador de Linux. Pido disculpas por los errores estúpidos que cometí en el camino, ya que ni siquiera ha pasado una semana desde que descargué Haiku por primera vez.
Quiero lograr tres objetivos:
- Portar una aplicación CLI simple
- Portar una aplicación desde GUI a Qt
- Luego empaquetelos en formato hpkg (ya que todavía estoy pensando en adaptar AppDir y AppImage para Haiku...)
Empecemos. En secciones и y así en Desde HaikuPorts encontré la dirección correcta. Incluso hay un libro PDF en línea. .
467 páginas - ¡y esto es de 1997! Da miedo mirar dentro, pero espero lo mejor. Las palabras del desarrollador son alentadoras: "ha tardado mucho porque BeOS no era compatible con POSIX", pero Haiku "en su mayor parte" ya es así.
Portar una aplicación CLI simple
La primera idea fue portar la aplicación. , pero resultó que esto ya es hace mucho tiempo.
Primer intento: nada que ver
Lo que no puedo entender es que ya - a pesar de que el sistema operativo en sí ni siquiera es la versión 1.0 todavía.
Segundo intento: necesito reescribir
Entonces usaré , CLI para controlar la impresora Brother P-Touch 770 que uso para imprimir etiquetas.
Imprimo varias etiquetas y es posible que ya lo hayas visto en el artículo anterior. Un poco antes, escribí un pequeño programa contenedor GUI en Python (dado que está en Gtk+, habrá que reescribirlo, y esta es una buena razón para aprender).
Impresora de etiquetas Brother P-Touch 770. ¿Funcionará con Haiku?
El administrador de paquetes Haiku conoce bibliotecas y comandos, por lo que si recibo el mensaje "no puedo encontrar libintl" cuando ejecuto configure - acabo de lanzar pkgman install devel:libintl y se encontrará el paquete requerido. Asimismo pkgman install cmd:rsync. Bueno, etc
Excepto cuando esto no funciona:
/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 foundQuizás udev esté demasiado basado en Linux y por lo tanto no exista para Haiku. Lo que significa que necesito editar el código fuente que estoy intentando compilar.
Eh, no puedes saltar por encima de tu cabeza y ni siquiera sé por dónde empezar.
Tercer intento
Sería bueno tener tmate para Haiku, entonces permitiría que los desarrolladores de Haiku se conecten a mi sesión de terminal, en caso de que algo salga mal. Las instrucciones son bastante simples:
./autogen.sh
./configure
make
make installSe ve bien, así que ¿por qué no probarlo con 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 foundEn este paso abro HaikuDepot y busco curses.
Se encontró algo que me dio una pista para una consulta más competente:
/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 foundNuevamente fui a HaikuDepot y, por supuesto, encontré devel:msgpack_c_cpp_devel. ¿Cuáles son estos nombres extraños?
/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 1En este paso, me di cuenta de que migrar un programa a Haiku requiere mucho más conocimiento del que se necesita para una reconstrucción simple.
Hablé con los amigables desarrolladores de Haiku, resulta que hay un error en msgpack y después de unos minutos veo un parche en HaikuPorts. Puedo ver con mis propios ojos cómo el paquete corregido (buildslave - máquinas virtuales).
Construyendo el msgpack corregido en buildmaster
Entre tanto envío un parche a upstream .
Cinco minutos después, el msgpack actualizado ya está disponible en 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.Inesperadamente bueno. ¡¿He dicho que?!
Vuelvo al problema original:
/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 1Ahora parece que msgpack no tiene la culpa. estoy comentando IMAXLABEL в tty.c como sigue:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);Resultado:
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.Bueno, allá vamos de nuevo... Por cierto:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... note dice dónde excavar:
/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.Aquí publiqué .
Me explicaron que hay algo más en libnetwork además de libresolv en Haiku. Aparentemente es necesario editar más el código. Necesidad de pensar…
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;La eterna pregunta: ¿qué está pasando?
/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 foundLo mismo, sólo que de perfil. Busqué en Google y . si agregas -lssp "a veces" ayuda, lo intento:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmate¡Guau! ¡Está comenzando! Pero…
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)Intentaré depurar :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1La “ID de puerto incorrecta” ya es como una tarjeta de presentación . ¿Quizás alguien tenga una idea de qué está mal y cómo solucionarlo? Si es así, actualizaré el artículo. Enlace a .
Portar la aplicación GUI a Qt.
Elijo una aplicación QML simple.
/> 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!Realmente simple. ¡Menos de un minuto!
Aplicaciones de embalaje en hpkg utilizando haikuporter y haikuports.
¿Con qué debería empezar? No hay documentación simple, voy al canal #haiku en irc.freenode.net y escucho:
- Equipo
package- una forma de bajo nivel de crear paquetes. En su mayor parte, PackageInfo es suficiente para ella, como se describe en la sección "Cómo convertirlo en un paquete .hpkg adecuado". - Necesito hacer algo
- Puede usar (se bloquea para mí, )
No está claro qué hacer. Supongo que necesito una guía para principiantes al estilo Hola Mundo, idealmente un vídeo. Sería bueno tener también una introducción conveniente a HaikuPorter, como se hace en GNU hello.
Estoy leyendo lo siguiente:
haikuporteres una herramienta para crear proyectos de paquetes comunes para Haiku. Utiliza el repositorio HaikuPorts como base para todos los paquetes. Las recetas de Haikuporter se utilizan para crear paquetes.
Además descubro que:
No es necesario almacenar recetas en el almacenamiento de HaikuPorts. Puede crear otro repositorio, colocar las recetas en él y luego señalarlo con haikuporter.
Justo lo que necesito, si no estoy buscando una manera de publicar el paquete. Pero este es tema para otro post.
Instalación de haikuporter y 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.confEscribiendo una receta
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
}Armando la receta
guardo el archivo con el nombre QtQuickApp-1.0.recipe, después de lo cual lanzo aikuporter -S ./QuickApp-1.0.recipe. Se verifican las dependencias de todos los paquetes en el repositorio. , lo que lleva algún tiempo. Iré a tomar un café.
¿Por qué debería realizarse esta verificación en mi máquina local y no centralmente en el servidor una vez para todos?
Según el sr. chapoteo:
De tal manera que puedas reescribir cualquier archivo en el repositorio 😉 Puedes optimizar esto un poco, calculando la información necesaria cuando sea necesario, porque los últimos cambios realizados son bastante raros.
~/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 repositoryResulta que no existe un archivo de recetas normal que contenga el código fuente de su aplicación. Debe guardarlo en un repositorio en formato HaikuPorts.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeEste hecho hace que el montaje sea más engorroso. No me gusta especialmente, pero creo que es necesario para que eventualmente todo el software de código abierto aparezca en HaikuPorts.
Obtengo lo siguiente:
~/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.¿Qué ocurre? Después de leer irc hago:
~/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!Ha surgido una pregunta interesante. Si agrego una suma de verificación a la receta, ¿coincidirá con la última confirmación de git para una integración continua? (El desarrollador confirma: "No funcionará. Las recetas están diseñadas para ser relativamente estables").
Para divertirte, agrega a la receta:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Aún no satisfecho:
~/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¿Qué está haciendo? Después de todo, este es un repositorio de git, el código ya está allí directamente, no hay nada que descomprimir. Desde mi punto de vista, la herramienta debería ser lo suficientemente inteligente como para no buscar un desempaquetador si está encima de la URL de GitHub.
Quizás uri git:// funcione
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Ahora se queja así:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!Mmmm, ¿por qué todo es tan complicado? ¿Por qué no puedes “simplemente trabajar”? Después de todo, no es tan raro crear algo desde GitHub. Ya sean herramientas que funcionan de inmediato, sin necesidad de configuración o, como yo lo llamo, "preocupaciones".
Quizás funcione así:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"No. Todavía recibo este extraño error y lo hago.
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confEstoy avanzando un poco más, pero ¿por qué me grita (¡GitHub no es seguro!) Y todavía intento descomprimir algo.
según :
Bueno, sí, el motivo fue el deseo de comprobar la integridad de los datos recibidos para el montaje. Una de las opciones es verificar la suma de verificación del archivo, pero, por supuesto, puede realizar un hash de archivos individuales, lo cual no se implementará porque lleva mucho más tiempo. La consecuencia de esto es la "inseguridad" de git y otros VCS. Lo más probable es que este siempre sea el caso, ya que crear un archivo en GitHub es bastante fácil y, a menudo, más rápido. Bueno, en el futuro, tal vez el mensaje de error no sea tan llamativo... (ya no fusionamos este tipo de recetas en 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 2Por costumbre, voy a preguntarle a gente buena en el canal #haiku de la red irc.freenode.net. ¿Y dónde estaría sin ellos? Después de la pista, me di cuenta de que debería usar:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Bien, quedó claro lo que hace: descarga un archivo con el código fuente de una determinada revisión. Es estúpido, desde mi punto de vista, y no es exactamente lo que quería, es decir, descargar la última revisión de la rama maestra.
Uno de los desarrolladores lo explicó de esta manera:
Tenemos nuestro propio CI, por lo que todo lo que se coloque en el repositorio de haikuports se empaquetará para todos los usuarios y no queremos arriesgarnos a recopilar y entregar "todo en la última versión".
¡Comprendido! En cualquier caso, esto es lo que pasó:
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
(...)Lo repite hasta el infinito. Aparentemente esto es un error (¿hay alguna aplicación? No pude encontrarla).
С haikuporter y repositorio No tiene la sensación de "simplemente funciona", pero como desarrollador, hay algunas cosas que me gustan de trabajar con Haiku. En su mayor parte, es similar al Open Build Service, un conjunto de herramientas para crear compilaciones de Linux: extremadamente potente, con un enfoque sistemático, pero excesivo para mi pequeña aplicación de "hola mundo".
De nuevo, según el sr. chapoteo:
De hecho, HaikuPorter es bastante estricto por defecto (¡además hay un modo lint y un modo estricto para hacerlo aún más estricto!), pero sólo porque crea paquetes que funcionarán, en lugar de simplemente crear paquetes. Por eso se queja de dependencias no declaradas, bibliotecas no importadas correctamente, versiones incorrectas, etc. El objetivo es detectar todos y cada uno de los problemas, incluidos los futuros, antes de que el usuario se dé cuenta (es por eso que no fue posible instalar avrdude, porque la dependencia en realidad estaba especificada en la receta). Las bibliotecas no son sólo paquetes individuales o incluso versiones SO específicas. HaikuPorter asegura que todo esto se observa en las propias recetas para evitar errores durante la ejecución.
En principio, este nivel de rigor está justificado a la hora de crear un sistema operativo, pero me parece innecesario para una aplicación de “hola mundo”. Decidí probar algo más.
Creación de aplicaciones en formato hpkg usando el comando "crear paquete"
Tal vez ¿Las instrucciones simples funcionarán mejor para mí?
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 menuInesperadamente rápido, inesperadamente simple, inesperadamente efectivo. Exactamente como me gusta, ¡increíble!
Instalación: ¿qué y dónde?
Se movió el archivo QtQuickApp.hpkg a ~/config/packagesusando un administrador de archivos, después de lo cual QtQuickApp apareció mágicamente en ~/config/apps.
De nuevo, inesperadamente rápido, sencillo y eficaz. ¡Asombroso, increíble!
Pero... (¡dónde estaríamos sin ellos!)
La aplicación aún no aparece en la lista del menú de aplicaciones ni en QuickLaunch. Creo que ya sé cómo solucionarlo. En el administrador de archivos muevo QtQuickApp.hpkg de ~/config/packages a /system/packages.
No, todavía falta. Aparentemente, (bueno, y las instrucciones) me perdí algo.
Después de mirar la pestaña "Contenido" en HaikuDepot para ver otras aplicaciones, vi que hay archivos como /data/mimedb/application/x-vnd... lo que es aún más notable es /data/deskbar/menu/Applications/….
Bueno, ¿qué debería poner ahí? Vamos...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataEstoy bastante seguro de que este truco funcionará, pero las preguntas persisten: ¿por qué es necesario, para qué sirve? Creo que esto arruina la impresión general de que el sistema es tan sofisticado.
Según lo explica el Sr. chapoteo:
A veces hay aplicaciones que otras aplicaciones necesitan pero que no están en el menú. Por ejemplo, LegacyPackageInstaller en su captura de pantalla, procesa archivos .pkg en formato BeOS. Me gustaría que los usuarios los instalaran, pero su presencia en el menú generará confusión.
Por alguna razón me parece que hay una solución más sencilla, por ejemplo Hidden=true en archivos .desktop en Linux. ¿Por qué no convertir la información "oculta" en un recurso y atributo del sistema de archivos?
Lo que no es especialmente sutil es el nombre de (alguna) aplicación que muestra el menú, deskbar, rígidamente atado a lo largo del camino.
señor. waddlesplash explica esto:
"Barra de escritorio" en este caso debe entenderse como una especie de término general (de manera muy similar a "barra de tareas", que se refiere tanto a la aplicación de Windows como al concepto general). Bueno, desde esto
deskbar, no “Deskbar”, esto también se puede entender de manera similar.
2 directorios "casi idénticos" con aplicaciones en ellos
¿Por qué hay 2 directorios con aplicaciones y también por qué mi QtQuickApplication está en uno, pero no en el otro? (Después de todo, este no es un sistema, sino un segundo usuario, lo que personalmente me resultaría comprensible).
Estoy realmente confundido y creo que esto debería estar unificado.
comentario del sr. chapoteo
El catálogo de aplicaciones contiene aplicaciones que no son necesarias en el menú. Pero la situación con el menú realmente necesita mejorarse para hacerlo más personalizable.
Solicitud, o no sucederá 😉
Me preguntaba: ¿es realmente necesario alojar aplicaciones en /system/apps, si los usuarios los ven allí, no es deseable. ¿Quizás sería mejor colocarlos en otro lugar donde el usuario no los encuentre? Tal como se hace en Mac OS X, donde el contenido de los paquetes .app, que no debería ser visible para el usuario en /Applications, escondido en las profundidades de /System/Library/…“`.
¿Qué pasa con las dependencias?
Creo que vale la pena especificar las dependencias de alguna manera, ¿verdad? ¿Se puede considerar Qt como parte obligatoria de la instalación de Haiku de forma predeterminada? ¡No! Qt no está instalado de forma predeterminada. ¿Puede un creador de paquetes detectar dependencias automáticamente al verificar los archivos ELF? Me dijeron que HaikuPorter realmente hace esto, pero package No. Esto se debe a que es sólo un "creador de paquetes" que simplemente crea archivos por sí solo. hpkg.
¿Debería hacerse Haiku más sofisticado agregando una política según la cual un paquete no debería tener dependencias de paquetes fuera de Haiku? haikuports? (Me gustaría hacerlo, porque una política de este tipo facilitaría mucho las cosas: el sistema podría resolver automáticamente las dependencias de cada paquete descargado desde cualquier lugar, sin tener que jugar con fuentes de paquetes adicionales).
señor. waddlesplash explica:
No nos gustaría limitar tanto la libertad de los desarrolladores, porque es obvio que si CompanyX quiere soportar su propio conjunto de software con dependencias (y por tanto un repositorio), lo hará con total libertad.
En ese caso, podría valer la pena recomendar que los paquetes de terceros eviten dependencias de cualquier cosa que no esté incluida en haikuports empaquetando completamente todo lo necesario con la aplicación. Pero creo que este es un tema para un futuro artículo de esta serie. [¿Se dirige el autor hacia AppImage? — aprox. traductor]
Agregar un ícono de aplicación
¿Qué sucede si quiero agregar uno de los íconos integrados a los recursos de mi aplicación recién creada? Resulta que este es un tema asombroso, por lo que será la base del próximo artículo.
¿Cómo organizar compilaciones continuas de aplicaciones?
Imagine un proyecto como Inkscape (sí, soy consciente de que aún no está disponible en Haiku, pero es conveniente mostrarlo en él). Tienen un repositorio de código fuente. https://gitlab.com/inkscape/inkscape.
Cada vez que alguien envía sus cambios al repositorio, se inician canales de compilación, después de lo cual los cambios se prueban, crean y empaquetan automáticamente la aplicación en varios paquetes, incluido AppImage para Linux (un paquete de aplicación independiente que se puede descargar para pruebas locales independientemente). qué puede o no estar instalado en el sistema [¡Lo sabía! — aprox. traductor]). Lo mismo sucede con cada solicitud de fusión de rama, por lo que puede descargar la aplicación creada a partir del código propuesto en la solicitud de fusión antes de fusionar.
Solicitudes de combinación con estados de compilación y la capacidad de descargar los archivos binarios compilados si la compilación se realiza correctamente (marcados en verde)
La compilación se ejecuta en contenedores Docker. GitLab ofrece ejecutores gratuitos en Linux, y creo que sería posible incluir sus propios ejecutores (por cierto, no veo cómo funcionaría esto para sistemas como Haiku, que sé que no tienen Docker o equivalente, pero Además, para FreeBSD no existe Docker, por lo que este problema no es exclusivo de Haiku).
Idealmente, las aplicaciones Haiku se pueden crear dentro de un contenedor Docker para Linux. En esta situación, el ensamblaje para Haiku se puede introducir en las tuberías existentes. ¿Hay compiladores cruzados? ¿O debería emular todo Haiku dentro de un contenedor Docker usando algo como QEMU/KVM (suponiendo que funcione de esa manera dentro de Docker)? Por cierto, muchos proyectos utilizan principios similares. Por ejemplo, Scribus hace esto: ya está disponible para Haiku. Un día llegará el día en que pueda enviar. Extraiga solicitudes a otros proyectos para agregar compatibilidad con Haiku.
Uno de los desarrolladores explica:
Para otros proyectos que deseen crear paquetes ellos mismos, se admite el método normal CMake/CPack. Se pueden admitir otros sistemas de compilación llamando directamente al programa de compilación del paquete, lo cual está bien si la gente está interesada en él. La experiencia lo demuestra: hasta ahora no ha habido mucho interés, por lo que haikuporter funcionó según nos convenía, pero, en última instancia, ambos métodos deberían funcionar juntos. Deberíamos introducir un conjunto de herramientas para software de compilación cruzada desde Linux o cualquier otro sistema operativo de servidor (Haiku no está diseñado para ejecutarse en servidores).
Doy una gran ovación. Los usuarios habituales de Linux llevan toda esta carga adicional y equipaje adicional (seguridad, control estricto, etc.) que es necesario para un sistema operativo de servidor, pero no para uno personal. Así que estoy completamente de acuerdo en que poder crear aplicaciones Haiku en Linux es el camino a seguir.
Conclusión
Es posible portar aplicaciones POSIX a Haiku, pero puede ser más costoso que una reconstrucción típica. Definitivamente estaría estancado en esto por mucho tiempo si no fuera por la ayuda de la gente del canal #haiku en la red irc.freenode.net. Pero ni siquiera ellos siempre se dieron cuenta inmediatamente de lo que estaba mal.
Las aplicaciones escritas en Qt son una fácil excepción. Creé una aplicación de demostración sencilla sin ningún problema.
Crear un paquete para aplicaciones simples también es bastante fácil, pero sólo para las "lanzadas tradicionalmente", es decir. tener archivos de código fuente versionados destinados al soporte en haikuports. Para una compilación continua (compilación para cada confirmación de cambios) con GitHub, todo parece no ser tan simple. Aquí Haiku se parece más a una distribución de Linux que al resultado de una Mac, donde cuando haces clic en el botón "Construir" en XCode obtienes un paquete. .app, listo para ser insertado en una imagen de disco .dmg, preparado para descargar en mi sitio web.
La creación continua de aplicaciones basadas en un sistema operativo de "servidor", por ejemplo Linux, probablemente será posible si hay una demanda por parte de los desarrolladores, pero por el momento el proyecto Haiku tiene otras tareas más urgentes.
¡Inténtalo tú mismo! Después de todo, el proyecto Haiku proporciona imágenes para arrancar desde DVD o USB, generadas . Para instalar, simplemente descargue la imagen y escríbala en una unidad flash usando
¿Tiene usted alguna pregunta? Te invitamos a los de habla rusa. .
Resumen de errores:
De traducción: este es el quinto artículo de la serie sobre Haiku.
Lista de artículos:
Fuente: habr.com