Le 08/10/07, Julien L.<[EMAIL PROTECTED]> a écrit :
>
> > Là je vois s'ouvrir une solution, liée à un souhait personnel :-)
> > Comme je le dis souvent, le problème des gestionnaires de paquets
> > 'classiques' est de trop s'appuyer sur leur base de donnée pour
> > effectuer leurs tâches. Il me semblerait plus 'cool', plus précis,
> > plus souple, d'utiliser la recherche sur les fichiers présents dans le
> > système de fichiers qu'une basée sur la base de donnée des fichiers
> > installés.
>
> A vrai dire, je suis un peu perplexe sur l'intérêt de la chose. Si tu as ce
> besoin , c'est que tu installes tes logiciels par différents moyens. Je me
> demande si ce n'est pas un peu contraire à l'idée du gestionnaire de paquets.
>
Pas contraire, complémentaire. Et je trouve un grand intérêt. Mon
problème sur la plupart des distros, c'est que je voudrais installer
certains paquets manuellement, tout en permettant qu'ils soient
'détectés' pour servir de dépendance à d'autres paquets. On tombe
exactement dans ce cas. Avoir le confort du système de dépendance sans
en être prisonnier
> > Le problème que tu soulève, n'est pas forcément un problème
> > pour tout le monde, et peut également disparaître lorsqu'on utilise un
> > outil alternatif à bon escient.
>
> Je croyais que tu voulais minimiser les dépendances sur Ncooker ? ;)
Pas une dépendance nécessaire. Bien-sûr Ncooker utiliserait find si
slocate n'est pas dispo (pour moi ça tombait sous le sens, désolé :-))
> Si je résume, nous avons trois moyens de rechercher un fichier dépendant :
> 1) la recherche dans la base de données Npkg (plutôt performante, mais dépend
> d'un gestionnaire de paquets en particulier)
> 2) la recherche par find (très coûteuse, mais la plus précise)
> 3) la recherche par locate/slocate (plutôt rapide, mais nécessite la mise à
> jour d'une base de données)
>
> J'en rajouterais un quatrième :
> 4) la recherche par chemins prédéfinis
>
> Cela consisterait à avoir une liste de chemins prédéfinis ("/, /usr,
> /usr/share, /opt" par exemple) qu'on utiliserait pour rechercher un fichier
> dépendant. Si le fichier dépendant est "bin/sh", on chercherait dans
> "/bin/sh" puis "/usr/bin/sh", puis...
>
> Cette recherche est très peu coûteuse mais moyennement exacte (dû au fait que
> les chemins prédéfinis ne sont jamais exhaustifs).
>
>
> A partir de là, je pense qu'il ne faut pas nécessairement choisir l'une ou
> l'autre des recherches, mais plutôt qu'il faut les additionner.
>
> Dans un premier temps, la recherche pourrait consister à la séquence des
> recherches 1, 2 et 3 (la recherche 4 est définitement trop coûteuse selon
> moi).
>
> Dans un deuxième temps, cette séquence de recherche pourrait être
> paramétrable dans Ncooker.conf (en acceptant le choix 4, pour les
> courageux...)
>
> Qu'est-ce que vous pensez de tout ça ?
Je ne sais pas, faut voir, mais je retire l'idée maîtresse, et qui me
plait : le filtrage. En effet, le fulldeps ne s'occupe que des
binaires (executables et bibliothèques) et interpréteurs. Nul besoin
de rechercher tout le système de fichiers. On peut même se baser sur
le path ou lechain de recherche des bibliothèques pour simplifier la
config par défaut
pour les dépendances 'autres', là je pense qu'il ne faut pas définir
de chemins prédéfinis, mais plutôt des exclusions (là ou on n'ira
jamais chercher, comme /sys ou /proc). Le problème, c'est que tout ça
se complique, et risque de devenir fouilli non ?
--
Richard 'riri' GILL
jabber: [EMAIL PROTECTED]
http://riri.houbathecat.info
http://nasgaia.org
« Frimousse en excessivité émousse son expressivité »
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
