[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [linux] Re: Ca commence à bien faire (was: j'ai la 8.0 ;-))



--nodeps is your friend
mais a ce moment-la (ou avec --force) tu perds _TOUT_ l'interet des
rpms. Perso, je trouve le systeme des rpm beaucoup trop rigide (bonjour,
je suis le soft a et j'ai besoin de la lib b en version 0.2.1 or pas de
bol, sur le systeme se trouve cette lib en version 0.2.3 donc pof, je
refuse de m'installer)
Excuse-moi mais c'est une argumentation complètement débile !

"tu perds tout l'intérêt des RPMs" - ben oui, mais avec le système de la
Slackware, il n'y a pas de dépendances *du tout*.
Vraiment très intéressant, ton argumentation: c'est chiant parce qu'il y a
les dépendances de paquetages, on préfère tout compiler à la main ou installer
comme ça, sans vérification, et quand je te dis que tu peux très bien ignorer
les dépendances pour des paquetages bien précis à l'installation, tu me
dis que c'est mauvais aussi parce que tu passes autour des dépendances...
??? WTF ?
Faudrait vous décider les gars ;-)))

"trop rigide"... moui...
Il y aurait effectivement moyen de le faire un peu mieux, mais cela dépend
essentiellement de la manière dont tu fais tes paquetages. Et malheureusement,
peu de développeurs de libs se tiennent à l'idée: je change le numéro de
version majeur dès que j'introduis une incompatibilité avec la version
précédente.

Les shared libs sous UNIX (du moins sur les systèmes ELF) ont une assez bonne
gestion des versions grâce aux liens symboliques et au nom de la librairie qui
est stoqué lors du link de la librairie (option -soname=...).
p.ex.: ta lib s'appelle libmachin.so.1.2.3 et il y a tjs des liens symboliques
libmachin.so.1.2 et libmachin.so.1; il te faut aussiun libmachin.so pour
compiler et utiliser libmachin, et c'est pq tu ne retrouves les liens lib*.so
uniquement dans les paquetages de développement (-devel). Le nom interne de
la librairie est mis à "libmachin.so.1" (avec -soname). Lorsque tu fais le link
d'un programme qui utilise cette lib, le linker va stoquer le nom interne de
la librairie dans une section du binaire (donc libmachin.so.1).
Et c'est avec ce nom-là que la résolution des shared libs (par le linker
dynamique, ld.so) se fait à l'éxécution.
Donc si entre-temps tu as upgradé à la version 1.3.18 de libmachin, il n'y aura
pas de problème car elle a aussi le nom interne libmachin.so.1 et aura les
liens libmachin.so.1.3 et libmachin.so.1

On devrait faire ses RPMs de telle manière à refléter ces dépendances, ce qui
est fait automatiquement et fonctionne fort bien dans 99% des cas.
Le problème vient plutôt des développeurs qui écrivent les libs et qui ne font
pas tjs un choix très cohérent des numéros de versions de leurs libs.
Et bon, là, en tant que distributeur ou packager, tu ne sais rien faire...

Mais en gros, les dépendances "il me faut la lib b en version 0.2.1", ça ne
devrait jamais être le cas. RPM crée automatiquement une dépendance sur les
librairies sur la version stoquée dans la lib et utilisée sous UNIX (0 dans
ton cas).
Donc si tu as une 0.12.3, ou une 0.1.0, ça fait l'affaire aussi (en principe ;-)).

Tu as tjs la possibilité, comme packager, d'ajouter des dépendances "manuelles"
en plus des dépendances automatiques que RPM fait pour toi (mais que tu sais
également désactiver, option "autoreq: no"). Là, c'est un peu une question de
goût et ça dépend du packager.
Perso, je regarde les dépendances vérifiées lors du ./configure,
p.ex. SDL >= 1.1.4, gtk >= 1.2.12, etc...
et je les ajoute au RPM.

Et puis si tu as une 1.2.3 ou une 3.2.1, ben c'est normal que RPM rouspète parce qu'il
y a 99% de chances que tu auras des gros problèmes à cause d'incompatibilités dans
les symboles de la librairie.
Il te reste tjs la possibilité de dire --nodeps pour "m'en fous, installe quand
même".

Franchement, je ne vois vraiment pas où est le problème avec ce système de dépendances,
que ce soit RPM ou deb...

--
  -o) Pascal Bleser   ATOS Origin/Aachen(DE) |
  /\\         <pascal.bleser@atosorigin.com> |
 _\_v <guru@linuxbe.org>                     |
---------------------------------------------|
Jesus saves,Buddha makes incremental backups :
---------------------------------------------'


_______________________________________________
Linux Mailing List
LCP - 11 Mai - http://www.unixtech.be/lcp.php
Archives: http://www.unixtech.be/mailman/listinfo/linux