makefile - ¿checkinstall crea deb inútil?
(3)
No estoy seguro de si esto responde exactamente la pregunta, pero esto es lo que obtuve hasta ahora (en ubuntu lúcido, checkinstall 1.6.1):
Traté de construir un proyecto de código abierto, que funcionó perfectamente. Luego intenté empaquetarlo para debian:
checkinstall -D --install=no --pkgname=$PKGNAME --pkgversion=0.0.1 --pkgrelease="svn-001" [email protected] --strip=no --stripso=no --addso=yes
Esto básicamente falló en la misma Building file list... FAILED! ; y un grep: /var/tmp/tmp.NaoiwTHT6F/newfile: No such file or directory similar grep: /var/tmp/tmp.NaoiwTHT6F/newfile: No such file or directory se informó de grep: /var/tmp/tmp.NaoiwTHT6F/newfile: No such file or directory .
También probé con agregar make al final del comando checkinstall anterior, que tampoco hizo mucho.
Finalmente, intenté esto:
make clean
checkinstall -D --install=no --pkgname=$PKGNAME --pkgversion=0.0.1 --pkgrelease="svn-001" [email protected] --strip=no --stripso=no --addso=yes -d2 make
El cambio -d2 es para habilitar la depuración; y ... make volverá a ejecutar una vez más.
El -d2 imprimirá el directorio temporal:
debug: The temporary directory is: [ /var/tmp/tmp.NaoiwTHT6F ] , por lo que se puede verificar enumerando ... Y, de hecho, puedo confirmar que en mi caso no se genera un newfile (sin embargo, hay newfiles , newfiles.installwatch , newfiles-tar y newfiles.tmp ). De hecho, resulta que checkinstall es un script bash , por lo que uno puede confirmar que newfile solo aparece una vez en él:
$ grep ''newfile '' `which checkinstall`
grep ''^/home'' ${TMP_DIR}/newfile > /${TMP_DIR}/unwanted
Además, la depuración señalará estos archivos / directorios:
debug: INSTW_EXCLUDE=/dev,/path/to/myproject-build,/proc,/tmp,/var/tmp,
debug: INSTW_ROOTPATH=/var/tmp/tmp.NaoiwTHT6F
debug: INSTW_LOGFILE=/var/tmp/tmp.NaoiwTHT6F/newfiles.tmp
debug: INSTW_DBGFILE=/var/tmp/tmp.NaoiwTHT6F/dbgfile
Tenga en cuenta que, de forma predeterminada, se excluye la ruta a mi carpeta de compilación, /path/to/myproject-build , y ahí es donde este proyecto también almacena los ejecutables incorporados.
Aparentemente, cuando make in checkinstall continúa construyendo por primera vez, puede capturar los archivos ejecutables recientemente generados; se mostrarán en ${TMP_DIR}/newfile s ; sin embargo, en mi caso, el problema es que los ejecutables terminan bajo el mismo directorio donde se llama a checkinstall ; por lo tanto, en este diálogo:
Some of the files created by the installation are inside the build
directory: /path/to/myproject-build
You probably don''t want them to be included in the package,
especially if they are inside your home directory.
Do you want me to list them? [n]: y
Should I exclude them from the package? (Saying yes is a good idea) [y]: n
... Debo , de hecho, responder n ; de lo contrario, ¡no recibiría nada incluido! Puedo verificar los contenidos con:
dpkg --contents mytest.deb | less
Sin embargo, entonces el problema es que checkinstall :
- también incluye archivos
.o, así como directorios.svn - cuenta la ruta absoluta como relativa (no "enviará" automáticamente ejecutables para decir,
/usr/bin, y.sos a/usr/lib
En resumen: algunos de los enfoques anteriores pueden hacer que uno tenga un .deb que no está completamente vacío; pero eso no significa que uno tenga solo los archivos necesarios allí, o que sean enrutados a los destinos de instalación habituales ...
Bueno, espero que esto ayude al menos un poco,
¡Aclamaciones!
Tengo un programa de línea de comandos trivialmente simple que, literalmente, consta de una secuencia de comandos python y algunos scripts de shell auxiliar. Me gustaría aprender sobre el empaquetado de este programa, aunque es trivial.
Por lo que reuní, fui a la ruta de configuración / hacer / instalar. Como no tenía nada que configurar ni nada que hacer, simplemente creé un Makefile con nada más que una sección de instalación:
install:
cp ./myProgram /usr/bin/my-program
chown root:root /usr/bin/my-program
chmod 777 /usr/bin/my-program
cp -r ./ProgramResources /usr/lib/my-program
chown -hR root:root /usr/lib/my-program
chmod -R 777 /usr/lib/my-program
En este punto, mi programa se instala y funciona bien con sudo make install.
Luego, intento crear un archivo deb usando la instalación de verificación de la siguiente manera:
sudo checkinstall sudo make install
Parece pasar la parte de instalación, ya que informa de que fue exitosa, pero luego falla:
======================== Installation successful ==========================
cp: cannot stat `//var/tmp/tmp.jKCmESc0v7/newfiles.tmp'': No such file or directory
Copying files to the temporary directory...OK
Stripping ELF binaries and libraries...OK
Compressing man pages...OK
Building file list... FAILED!
Building Debian package...OK
Installing Debian package...OK
Erasing temporary files...OK
Deleting temp dir...OK
**********************************************************************
Done. The new package has been installed and saved to
...
El programa está instalado, pero hasta donde puedo decir, este archivo .deb recién hecho no hace nada. dpkg -L mi-programa solo produce
/.
y eliminarlo e instalarlo manualmente desde el archivo deb no parece hacer nada, en realidad no coloca ningún archivo en ningún lado.
Entonces, (1) ¿Hay algo mal con mi enfoque? y (2) ¿Cómo puedo solucionar el problema de la instalación de verificación?
Muchas gracias por las respuestas, aunque soy bueno con el código, nunca he sabido nada sobre empaque / distribución.
He tenido problemas similares. Al final seguí este enfoque muy simple, pero bastante manual.
Coloque los archivos que desea empaquetar en debian / usr / bin, por ejemplo. No es necesario completar los pasos habituales de configure, make, make install .
El doble uso de sudo es el problema.
Con un archivo install.sh me gusta
#! /bin/bash
set -x
touch useless
cp useless /usr/share/useless
mando
sudo checkinstall --pkgname useless -y ./install.sh
funciona mientras
sudo checkinstall --pkgname useless -y sudo ./install.sh
^^^^
muestra
cp: cannot stat ‘//var/tmp/tmp.Au4ympTNlT/newfiles.tmp’: No such file or directory
y produce un paquete vacío.