Re: backport Imagemagick
Le Fri, Oct 26, 2001 at 10:38:21AM +0200, georges mariano écrivait:
> Je voudrais qu'on m'explique pourquoi le "doit" ??
> Exemple, Le passage de samba2.0 a samba4.0, (pas de panique, c'est un
> exemple virtuel ;-) Si ça compile parfaitement avec la libc6 2.1,
> pourquoi le faire >obligatoirement< avec la 2.2 ??
Parce que le monde n'est pas aussi simple que tu veux bien le croire.
C'est indispensable si le "soname" de la bibliothèque change et que le
paquet dépendant est différent (exemple les != libgal). C'est le seul
moyen de se débarasser des dépendances sur des anciens paquets.
> Je vois vraiment pas l'intérêt en terme de stabilité
> (ça va obliger à mettre à jour plus de paquet que nécessaire
> donc plus de risques !)
Unstable est fait(e) pour *changer*. On n'a pas le genre de considérations
que tu évoques.
> un apt-get source -b qui foire parce qu'il demande les dernières libs
> __à la mode__ alors que derrière un debian/rules binary fonctionne
> (très) bien ...
Personne ne t'en voudra d'éditer les "Build-Depends" voire d'utiliser
l'option "-d" dans dpkg-buildpackage (que tu peux passer à debuild
également si tu l'utilises).
En attendant, spécifier des versions dans les Build-Depends c'est le
seul moyen qu'on a de s'assurer que les paquets seront recompilés avec
les bonnes versions sur les autobuilders.
> Tout ce que je demande c'est que les paquets pour lesquels il n'est
> pas __nécessaire__ de frimer ne nous __obligent__ pas à upgrader la
> moitié du système ...
Tu n'as besoin de rien upgrader pour essayer de compiler ...
> (merci de prendre en considération les __ __ qui sont pas là pour rien)
Merci de ne pas penser qu'à toi.
> Ceux qui disent que woody me semblent croire que 90% des paquets
> nécessitent le passage en woody, ben je suis désolé, mon backport du
> monde démontre (statistiquement) le contraire...
Donc la situation n'est pas si dramatique que cela ...
> En vrac, ') l'exemple fort-a-propos de /usr/share/doc, pourquoi tant
> de soucis pour la compatibilité descendante de fichiers de docs et,
> apparemment bcp moins de réflexion sur un truc comme perl ??
Je vais te dire un truc, tu m'énerves. Qu'est-ce qui te fait dire que
la transition pour perl a été mal gérée ?
Au contraire, tout est *très* propre. Pas forcément compatible avec le
monde du perl avant 5.6 mais bien plus clean pour l'avenir et les
prochaines mises à jour.
> '') je ne me souviens pas que la moitié des applis upstream linux
> induisent une mise à jour radicale dans leurs dernières versions suite
> à des modifs perl "amont". J'en déduis que le problème de transition
> perl est __spécifique__ Debian, et là, ça me mets très mal à l'aise...
Est-ce que tu peux détailler ce qui ne va pas ? J'ai l'impression que tu
racontes un peu n'importe quoi à tort et à travers.
> ''') pourquoi est-il si inconcevable de modifier le paquet
> xlib6g(-dev) actuellement dans potato, de lui rajouter les deux
Parce que potato ne prend plus de modifs autres que celles de sécurité.
> lignes, et régler ainsi pour une foultitude de paquets le problème
> de la recompilation ?? ça m'a pris 5mn chez moi (plutôt 15)...
Je te propose de lancer un projet "recompilation des paquets récents sur
stable" et de mettre à disposition tes paquets modifiés pour simplifier
la vie de ceux qui veulent faire comme toi ...
En attendant, ce n'est pas un objectif primordial pour Debian.
A+
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Le bouche à oreille du Net : http://www.beetell.com
Naviguer sans se fatiguer à chercher : http://www.deenoo.com
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: