À priori les concepts des paquets: version - dépendances à d'autres paquets sont identiques, mais les données, à savoir les paquets, sont différents suivant les distributions, c'est ça qui coinçait ?
C'est la même chose pour la mise en place de règles de firewall ....Les concepts sont les mêmes quel que soit le firewall, cependant construire un outil qui est capable de tous les géerer est assez compliqué. Aujourd'hui, on arrive à faire des choses qui "commmencent" à être intéressante. Cela dit ces outils montrent vite leurs limtes. Un exemple :
No. RPM is good at managing the core software of a distro. It's fast, well understood and supports features like prepatching of sources. What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles. Although in theory it'd be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.
La question que je me pose sur ce genre d'outil c'est que se pass-t-il si un prérequis système n'est pas installé ou n'a pas la bonne versoin ? Voila une limite". Et tot ou tard avec ce genre d'outil on se trouve confronté à ce genre de limite. La seconde : "it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.".
Cet outil serait certainement plus intéressant si les distributions Linux ne liaient pas autant le "core OS" et les packages applicatifs .... Ceci permettrait de faire sauter un premier verroou.
[^] # Re: autre point
Posté par totof2000 . En réponse au journal [Fantasme ergonomique] Interface graphique pour firewall. Évalué à 2.
C'est la même chose pour la mise en place de règles de firewall ....Les concepts sont les mêmes quel que soit le firewall, cependant construire un outil qui est capable de tous les géerer est assez compliqué. Aujourd'hui, on arrive à faire des choses qui "commmencent" à être intéressante. Cela dit ces outils montrent vite leurs limtes. Un exemple :
http://autopackage.org/faq.html?PHPSESSID=3e1bee0a19bb498f5a(...)
# Is autopackage meant to replace RPM?
No. RPM is good at managing the core software of a distro. It's fast, well understood and supports features like prepatching of sources. What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles. Although in theory it'd be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.
La question que je me pose sur ce genre d'outil c'est que se pass-t-il si un prérequis système n'est pas installé ou n'a pas la bonne versoin ? Voila une limite". Et tot ou tard avec ce genre d'outil on se trouve confronté à ce genre de limite. La seconde : "it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.".
Cet outil serait certainement plus intéressant si les distributions Linux ne liaient pas autant le "core OS" et les packages applicatifs .... Ceci permettrait de faire sauter un premier verroou.