Re: backport Imagemagick

2001-10-26 Par sujet Nicolas SABOURET
Raphael Hertzog wrote:
 
 Le Thu, Oct 25, 2001 at 10:03:51PM +0200, georges mariano écrivait:
  ben je reprendrai une suggestion faite ici (et pour laquelle je suis
  d'accord à 100%), un développeur devrait bosser sous potato sauf
  exigences spécifiques...
 
 Et là je suis 100% contre, en faisant cela, on ne passe jamais aux
 nouvelles versions des bibliothèques, et on ne bouge pas.
 

Bon, comme c'est moi qui est fait la suggestion, je suis obligé de
répondre :)
Il ne s'agit pas d'être à 100% pour ou contre. Même moi, je dois pas
être pour à plus de 80% :)

Plus sérieusement, en réponse à ce que Raphaël a dit, mon point de vue
est le suivant :
1. Oui, il faut que les paquets puissent recompiler sous stable
2. Oui, il faut que les paquets utilisent les nouvelles bibliothèques,
disponibles uniquement en unstable

Et je crois que dans de nombreux cas, c'est possible, si on (les
mainteneurs) fait l'effort :
1. De compiler son nouveau paquet sous stable
2. Une fois que ça marche, de passer à unstable et de le compiler sous
unstable, et d'uploader cette version
3. Si pour faire 2, on doit faire des changements, il faut faire en
sorte que ça soit compatible avec 1.
4. Comme tout le monde fait ça (rires), on peut facilement recompiler
aussi les nouvelles libs dont on a besoin sous stable, donc faire 1.
avec les nouvelles libs.

Ça veut dire, pour les mainteneurs, bosser en stable et backporter le
monde dès qu'on a un paquet qui est un peu trop dépendant ...

Je sais, ça parait fou et c'est totalement impossible quand, par
exemple, la version de perl change (c'est ce que j'ai appelé dans un
mail précédent un gros changement du système).

Mais c'est quand même faisable sur certains paquets. Par exemple avec un
miroir officiel paquets de debian-devel pour stable.

Je suis pourtant d'accord avec toi (Raphaël) quand tu dis :

 les problèmes de recompilation, tu peux difficilement les éviter 
 [...] quand on a de si grands écarts (temporels et fonctionnels)
 entre deux versions

Le cas de Perl est flagrant.

Mais j'ai l'impression (et je pense que c'est cette même impression qui
met GM de mauvais poil ;-)) que certains mainteneurs ne font pas
l'effort d'essayer de se poser la questions de savoir si peut-être y'a
une chance pour qu'en y réfléchissant un peu ... le paquet puisse
compiler sous potato.

Si 1 mainteneur travaille en potato, il va se faire ch... pour rien. Ça
ne peut pas marcher. Mais si tous les mainteneurs essayent de travailler
en stable et de backporter ce dont ils ont besoin, alors :
1. on pourrait avoir des stable étendues plus facilement
2. peut-être (je n'en suis pas sur parce que le problème me semble
orthogonal) qu'on pourrait avoir des versions stable plus fréquentes.

Maintenant, je suis aussi conscient des difficultés que peuvent avoir
les mainteneurs qui bossent sur des paquets modernes. Mais dans
l'ensemble, on arrive à avoir pas mal de paquets recompilés pour potato
(kernel2.4, kde, xfree4, etc), alors pourquoi ne pas rêver un peu.

Et puis si on ne parle pas de ça sur -devel-french, où va-t-on en parler
? :)

Nico.
-- 
Nicolas SABOURET
LIMSI-CNRS, BP133, 91403 Orsay, France
http://www.limsi.fr/Individu/nico




Re: backport Imagemagick

2001-10-26 Par sujet georges mariano
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:[EMAIL PROTECTED] 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




Re: backport Imagemagick

2001-10-26 Par sujet Jean-Christophe Dubacq
On Fri, 26 Oct 2001, georges mariano wrote:

 Mon objectif est de faire fonctionner bientôt dix machines en
 permanence en expliquant aux utilisateurs pourquoi il est si
 difficile de mettre sur les machines debian/potato telle ou telle
 applis (dans sa dernière version) dont dipose sans problème le
 premier mandrakien venu ...

Parce que tu crois que ca ne casse rien dans sa Mandrake ?

-- 
Jean-Christophe Dubacq -- ATER en informatique à la faculté d'Orsay.
Tel: 01 69 15 76 43 / 06 64 86 10 56 --- Email: [EMAIL PROTECTED]




Re: backport Imagemagick

2001-10-26 Par sujet Denis Barbier
On Fri, Oct 26, 2001 at 12:12:34PM +0200, georges mariano wrote:
 On Fri, 26 Oct 2001 11:25:09 +0200  Roland Mas [EMAIL PROTECTED] wrote:
 
 RMLa possibilité d'upgrader un système.  Si l'état initial est connu
 RM  (la stable précédente ou celle d'avant), on peut.  S'il est inconnu
 RM  parce que le mec s'est installé des paquets rétroportés à différents
 RM  moments, on peut pas upgrader de manière déterministe (ou alors, il
 RM  faut prendre en compte toutes les combinaisons possibles d'upgrades
 RM  intermédiaires).
 
 
 
 Le principe fondamental des OS modernes c'est de garder autant que possible
 une independance entre les couches existantes. En matiere de (re)compilation
 de softs ceci est assuré par les mécanismes (sophistiqués) d'éditions
 de liens, de chargement dynamique etc ... On peut envisager d'avoir plusieurs
 version d'une même librairies et jouer ensuite sur les réglages possible.
 Moralité : Ce premier paragraph (celui de RM!) est orthogonal à une bonne 
 perception de ce quoi doit faire un OS moderne comme Linux/Debian...
[...]

Dans le genre « je dis n'importe quoi », je te ferai remarquer que pour
l'instant c'est toi le vainqueur, ton diagnostic sur les problèmes
rencontrés avec imagemagick était complètement délirant. Est-ce que tu
comptes l'admettre un jour, ou tu vas me démontrer que c'est en fait
moi qui me suis trompé ?

Sur le fond, ce n'est pas la peine de répondre, puisqu'apparemment tu as ta
propre définition de ce qu'est la stabilité de Debian, et ceux qui n'ont
pas la même ne sont que des abrutis.

Oui, il y a des problèmes, certains développeurs font du travail de merde,
certaines décisions techniques visent à favoriser la vie des autobuilders
en se foutant des implications sur les utilisateurs, mais si ton but est
que ça change, il faudrait essayer d'être productif et proposer des idées
pour qu'elles soient relayées.

Denis




Re: backport Imagemagick

2001-10-26 Par sujet georges mariano
On Fri, 26 Oct 2001 14:36:19 +0200  [EMAIL PROTECTED] (Denis Barbier) wrote:

DB  On Fri, Oct 26, 2001 at 12:12:34PM +0200, georges mariano wrote:

DB  Dans le genre « je dis n'importe quoi », 

DB  Oui, il y a des problèmes, 
Faudrait savoir...

DB  certains développeurs font du travail de merde,
pas celui de ImageMagick donc...
DB  certaines décisions techniques visent à favoriser la vie des autobuilders
pas celles qui tournent autour d'autoconf ou des différents organisations
de perl donc...
DB  en se foutant des implications sur les utilisateurs, 

J'ai pas de bol, je tombe toutjours sur de mauvais exemples de vrais
problèmes ... comment voulez-vous être crédible après ça...

DB  mais si ton but est que ça change, 
 Pourquoi devrais-je avoir un but (sous-entendu dans la 
ligne Debian) ? Mon seul objectif, c'est d'avoir un système qui réponde
à mes besoins. Mais quand on me répond que le système Debian est l'un des
plus stable quitte à réinstaller la moitié de l'environnement des utilisateurs
actuels pour une histoire de Debian Policy, je m'interroge.

DB  il faudrait essayer d'être productif et proposer des idées
Personnellement, je me sens productif ici, en backportant ce dont nous avons
besoins, je nous évite (enfin je crois) pas mal de problèmes de ...
stabilité (cf la liste user). C'est toute mon ambition, même si elle passe
par une technique que certains prennent pour impossible...

DB  pour qu'elles soient relayées.
 Ben si mes diagnostics sont étiquetés comme n'importe quoi, c'est plutôt
foutu d'avance non ???

A+ 

-- 
# mailto:[EMAIL PROTECTED] 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




un chti coup de bonne volonté...

2001-10-26 Par sujet georges mariano

ça me changera...

quelqu'un peut-il m'indiquer dans la foultitude de doc Debian,
où est spécifié/décrit le cheminement d'un paquet tout frais
tout neuf, depuis son arrivée dans ... incoming?
(y'a un truc avant ??)
jusqu'à ce qu'il arrive dans sid/woody...
c'est surtout le cheminement du paquet source qui m'intéresse ...

j'ai cru entrevoir que certains paquets étaient automatiquement(?)
rejetés ... jevoudrais savoir comment/pourquoi...

et pis, où on trouve de la doc sur ces bête mysèrieuses appelées
autobuilder ...

A+

PS : je vous raconte mon dernier manque de bol ?? ;-)
non ... je déconne. Il est relativement banal.


-- 
# mailto:[EMAIL PROTECTED] 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