Forum Linux.général Attributs étendus automatiques

Posté par (page perso) .
Tags : aucun
0
31
mai
2005
Depuis un petit bout de temps j'étudie les différents systemes de gestion de packetage, pour essayer de trouver quelque chose de simple pour gerer une LFS.
J'ai abandonner pour des raison diverse et varriées les differents programme que j'ai pu trouver, et donc je me suis mis en tete de voir ce que je pouvais faire tout seul... (et oui comme tout le monde j'ai un ego demeusurer et j'aime beaucoup inventer la roue)

J'ai comencer par un LD_PRELOAD, mais le probleme, c'est que les avec LFS les binnaires du toolkit sont liee statiquements, donc...
Ensuite je me suis attaquer un ptrace, pour intercepter les syscall, mais la c'est quand meme super bourin, et pas portable du tout... (en plus j'ai toujours pas reussit a le faire marcher comme je veux)

Et la je me suis dit : Mon objectif est de savoir pour chaque fichier, a quel paquet il appartient, et dans 99% des cas le seul moment ou ca m'interresse, c'est quand je veux virer un programme. Or ce n'est pas une chose qui arrive souvent, donc je peux perdre du temps a ce moment ce n'est pas grave. Donc si je met sur chaque fichier un attribut etendu qui indique a quel paquet il appartient, pour supprimmer un paquet je cherche tous les fichier qui on cet attribut et je les vire.

Ca c'est l'idee de depart qu'il va falloir pas mal developee, mais la grande question que je me pose est : (roulement de tambourts)

Est-il possible de specifier un attribut qui doit etre donner a tous les fichier qui von etre creer ?

Soit a tous les fichier creer par un processus et ces fils (le processus qui install) ou a un user (avant chaque install on fixe l'attribut, et apres l'install on le vire).
Google ne me dit rien la dessus, mais les attributs etendus ne sont pas encore tres rependus donc... et je me dis que peut-etre que quelqu'un les connaissant mieux que moi aura une idee ?
  • # j'ai pas tout suivi

    Posté par (page perso) . Évalué à 2.

    Lorsque j'avais fait ma LFS, j'avais fait un petit systeme de packet, le but était simple : lister la liste des fichiers qu'un programme installe. Pour les dépendances, on s'en fout (faut le dire vite), puisque le ./configure s'en occupe !
    Tu ./configure && make && make install dans un fakeroot (/tmp/fakeroot par exemple) pour chopper la liste des fichiers, que tu sauvegarde, et puis tu clean et rebelote avec --prefix=/usr/local
    et voila !
    ensuite tu parse tes fichiers de config ( kdelibs.ls par exemple ) qui contient la liste des fichiers installés.
    • [^] # Re: j'ai pas tout suivi

      Posté par (page perso) . Évalué à 1.

      Pour les dependance, la gestion sera manuelle, l'objectif est juste de pouvoir virer proprement les programmes (et d'autre broutilles, mais on verra apres)

      Pour le fakeroot, si tu veux parler du truc de debian (http://fakeroot.alioth.debian.org)(...) ça ne marche pas vu qu'il utilise le LD_PRELOAD qui ne supporte pos les binnaires statiques et suid.
      Si tu veux parler d'un prefix a l'install, le probleme c'est que ça complique tout de suite pas mal l'install, car tous les programme ne le gerent pas en standard, et ceux qui le gerent ne le font pas tous de la meme maniere, donc surcharge de boulot. (en general seul les prog qui utilisent autoconf le font a peu pres correctement)

      En plus les logiciels mal programmer qui hardcode des chemins dans le binnaire bug parfois avec cette methode.
    • [^] # Re: j'ai pas tout suivi

      Posté par . Évalué à 3.

      Tu ./configure && make && make install dans un fakeroot (/tmp/fakeroot par exemple) pour chopper la liste des fichiers, que tu sauvegarde, et puis tu clean et rebelote avec --prefix=/usr/local
      et voila !

      Plus simplement :
      $ ./configure --prefix=/usr
      $ make install
      $ make install DESTDIR=/tmp/fakeroot
      $ find /tmp/fakeroot/ | sed 's|^/tmp/fakeroot||' | sort > install_list

      Une seule compilation dans ce cas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.