• [^] # Re: Jusqu'où aller ?

    Posté par . En réponse à la dépêche CARE et la reproductibilité des exécutions. Évalué à 7.

    Pour une appli KDE ou Gnome, ca peut poser des problèmes car les applications dépendent d'autres services lancées par le desktop (dbus, ...), qui sont accédés via un mécanisme d'IPC. Donc ça ne sera pas embarqué dans l'archive.

    Pour résoudre ce problème de dépendance à des services "externes", la notion de chemins et variables d'environnement "volatiles" a été introduite dans CARE. Ceux-ci ne sont pas archivés, mais comme "ré-injecté" dynamiquement dans l'archive depuis le système où l'on ré-exécute. Par défaut (on peut les enlever ou en ajouter) les chemins volatiles sont:

    • /dev
    • /proc
    • /sys
    • /run/shm
    • /tmp/.X11-unix
    • /tmp/.ICE-unix
    • $XAUTHORITY
    • $ICEAUTHORITY
    • /var/run/dbus/system_bus_socket
    • /var/tmp/kdecache-$LOGNAME

    et les variables d'environnement volatiles sont:

    • DISPLAY
    • http_proxy
    • https_proxy
    • ftp_proxy
    • all_proxy
    • HTTP_PROXY
    • HTTPS_PROXY
    • FTP_PROXY
    • ALL_PROXY
    • DBUS_SESSION_BUS_ADDRESS
    • SESSION_MANAGER
    • XDG_SESSION_COOKIE

    Cela implique que le système où l'on ré-exécute possède un service "compatible", ou bien d'archiver le service avec. Par exemple en démarrant KDE sous CARE, comme tu l'as suggèré.

    La bonne manière de faire est probablement de démarrer carrément KDE avec CARE, mais bonjour la taille de l'archive !

    Je viens de tester "care startkde" en laissant bien le temps à KDE d'accéder à toutes ses ressources (icons, .desktop, ...): le .bin fait 203Mo et le .tar.xz fait 95Mo. À noter qu'il n'y a pas le serveur X dans cette archive.

    Et encore, est-ce que CARE gère les forks et continue à suivre les deux processus ?

    Oui, il n'y a vraiment aucun soucis avec les applications multi-processus et/ou multi-threadées.