Re: backport Imagemagick
Bon un dernier pour la route...
RH > > d'accord à 100%), un développeur devrait bosser sous potato sauf
RH > > exigences spécifiques...
RH >
RH > Et là je suis 100% contre, en faisant cela, on ne passe jamais aux
RH > nouvelles versions des bibliothèques, et on ne bouge pas.
RH >
RH > Un développeur doit compiler sur unstable.
Alors faut faire de la pub basée sur l'unstabilité de Debian :)
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 ??
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 !)
[imagemagick _exige_ libdps alors que c'est pas _nécessaire_ ...]
Ce qui me mets vraiment de mauvais poil c'est
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 ...
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 ...
(merci de prendre en considération les __ __ qui sont pas là pour rien)
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...
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 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...
''') pourquoi est-il si inconcevable de modifier le paquet xlib6g(-dev) actuellement dans potato,
de lui rajouter les deux 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)...
Mais si j'ai bien compris c'est une hérésie chez Debian cause que potato est dans
le marbre ...
J'arrète là, la liste est longue des spécificités "packaging Debian" qui m'échappent.
Je conçois parfaitement que la politique Debian s'affine/évolue entre deux releases,
mais à partir du moment ou cette même politique m'oblige à gérer mon parc "à-la-windows"
en courant après la dernière version de tel ou tel paquet ... tout ça pour
pouvoir installer la dernière version d'un logiciel qui n'a rien voir avec ces décisions
je me demande où est le gain ...
A+
--
# mailto:Georges.Mariano@inrets.fr tel: (33) 03 20 43 84 06
# INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59
# BP 317 -- 59666 Villeneuve d'Ascq
# http://www3.inrets.fr/estas/mariano
Reply to: