Re: Backport XFree 4.3
On Wed, Jun 11, 2003 at 11:49:41PM +0200, Georges Mariano wrote:
> On Wed, 11 Jun 2003 21:17:00 +0200
> Sven Luther <sven.luther@wanadoo.fr> wrote:
>
> > Rappelle toi que c'est unstable/testing, si ces problemes persiste
> > lorsque sarge sera release, alors la tu aurra pleinement raison.
>
> Euh nan, le cas de zope c'est testing, et pour tetex c'est dans woody
> [il me semble] (mais je m'en suis aperçu très tard, j'étais en potato
> assez longtemps). Mais là n'est pas vraiment la question... le gros
> malaise c'est que ce soit arrivé «jusque là». Cette technique de
> récupération d'installation cassée après lecture de README.Debian, je
> m'y attendais pas du tout (de la part de Debian).
>
> > De plus, le travail de packaging ne consiste pas seulement a faire un
> > package, mais aussi d'integrer le package dans l'ensemble de debian et
> > le faire interagir avec les autres packages au mieux.
>
> ?? pour moi c'est (effectivement) un tout.
>
> > Mais biensur, la qualite des packages est relativement inegale,
> > dependant de la qualite du packageur, de son temps disponible, etc.
>
> ben ouai, mais c'est pas ta formulation initiale ... et je vois pas
> pourquoi sur les debian-*-users tout serait pour le mieux dans le
> meilleur des mondes alors que sur les debian-*-devel c'est une autre
> histoire ...
>
> > Donc, pour en revenir au sujet, et c'est en fait la seule raison pour
> > laquelle j'ai poste, c'est tout simplement parceque les packages
> ...
> > Malheureusement, il n'est pas facile de desactiver
> > la compilation de ces packages,
>
> mais dans certain référentiel de qualité, ne pas pouvoir désactivé
> facilement un truc qui a été activé c'est pas très «qualité»... ;-)
Comme dis, un patch est bienvenu ...
> PS : non, je n'ai pas besoin d'être "mainteneur" Debian pour que mes
> remarques soient recevables ;-)
Ni pour soumettre des patches :)))
Comme dis, Daniel Stone, qui est a la base des packages 4.3.0 n'est meme
pas developpeur debian.
> > mais tu est bienvenu a fournir un patch
> > si le coeur t'en dis.
>
> je l'attendais celle-là, tellement prévisible ;-)
> c'était juste de la curiosité...
Et j'espere avoir repondu.
> ceci dit, c'est pas la première fois où l'on verrait un debian/rules qui
> procède par copier-coller/adapter de règles pour générer ce genre de
> paquets dérivés au lieu de s'appeler avec un bon paramétrage ...
>
> ajoutons une couche avec, très souvent, une gestion à la hache des
> cibles de compilation (configure/build/...) qui casse toute la
> modularité du processus compilation upstream
Oui, peut-etre, mais je ne pense pas que cela soit le cas. Je ne suis
absolument pas en bonne relation avec Branden, depuis que j'ai
malencontreusement fait un NMU de X en 99 alors que X de debian ne
buildait pas sur powerpc, mais que la version upstream n'avait pas de
probleme. J'etait jeune developpeur a l'epoque et ne realisait pas
reellement la porte de ce que je faissait. Mais bon, malgres cela, j'ai
un grand respect pour le travail de Branden, il a fait un travail
formidable pour le packaging de XFree86, qui est l'un des packages le
plus difficile qui soit, specialement parce que upstream ne supporte que
3 ou 4 des 11 architectures que debian supporte, et qu'il faut plusieurs
jours pour compiler X sur m68k par exemple. Donc ton discours plus haut
est peut-etre vrai, mais pas dans le cas de X, c'est juste que le
systeme de build n'est pas prevu pour realiser la compilation partielle
d'un package multi-binaire, c'est tout. Mais comme dis, si cela te gene,
les patches sont les bienvenus, ce ne doit pas etre tres difficile a
faire d'ailleurs, c'est juste que les personnes qui s'en occupe n'ont
pas trouve que cela etait assez prioritaire pour qu'il s'en occupe (a la
place de quelque chose de plus urgent). Et de toute facon, cela ne
compromet en rien la qualite des packages binaires resultants, c'est
completement transparent pour les utilisateurs.
Sinon, je suis personnellement en train de travailler avec upstream pour
rendre la SDK fonctionnelle, et j'attend la release de 4.3.0-1 pour
pouvoir soumettre un patch qui produirait un nouveau package binaire
xfree86-sdk, si Daniel ne le fait pas avant moi, qui permettrait de
construire les drivers du CVS upstream facilement et de les utiliser
avec les packages 4.3.0. Ensuite je construirait un package debian
separe de xfree86 qui permettra de construire lesdits drivers et de les
installe de maniere conforme au systeme de packaging.
Une fois que cela sera fait, l'urgence d'utiliser ou de reconstruire les
packages Xfree86 pour stable diminue considerablement, car il suffira de
construire le package de drivers et l'installer, ou simplement installer
le package que je produirait. De plus, un tel package dependra uniquement
du package xfree86, et n'aura donc aucune dependance supplementaire.
C'est quand meme une maniere d'utiliser mon (tres limite) temps libre
plus interessant et productif a la longue que d'aller faire des choses
d'un interet limite comme modifier le build xfree86 pour produire qu'une
partie des packages, choses que les principals interesse ne sont meme
pas interesse par produire eux meme un patch, et prefere se plaindre. Et
de toute facon, je suis seule maitre de ce que je fait de mon temps
libre.
Amicalement,
Sven Luther
>
> etc etc
>
> on peut en ajouter ... tout dépend de ce que l'on appelle qualité ...
>
>
> A+
> --
> debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/
> val-linux: http://phalompe.homeip.net:9673/val-linux
> perso: http://www3.inrets.fr/estas/mariano
>
>
> --
> To UNSUBSCRIBE, email to debian-user-french-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: