On Mon, 20 Aug 2001 18:19:08 +0200 Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> Et qu'une fois une version stable est sortie, on ne modifie plus pour ce genre de d�tails. [et je r�ponds en utilisant le bouton "Tout r�pondre" de sylpheed 0.5.3, un petit myst�re � �claircir donc ... mais �a c'est pas grafff ] D�sol�, je ne vois pas en quoi cela est un d�tail... Le moindre octet est un d�tail qui peut faire exploser en vol une fus�e Ariane... Et je suis quelque peu surpris par la teneur du reste de la r�ponse > La recompilation automatique ne sert pas � grand chose ... ... � part avoir la derni�re version d'un soft sans risquer de bousiller ton install, je suis d'accord, �a sert pas � grand chose... > autant passer > en woody et la tester alors. Ben non, j'aimerai garder le choix sur mon statut ... i.e entre utilisateur Debian et testeur Debian, c'est pourquoi je suis en woody sur mon portable mais que les machines "communes" sont en potato (moyennant quelques recompilations sp�cifiques) [apart�, il faut arr�ter de consid�rer par d�faut un utilisateur linux comme un testeur, c'est r�ducteur ... et dommagable] Et j'ai pas envie de tout cass� parce que Xfree 4.0 (par ex) va �tre install� alors que les machines fonctionnent tr�s bien actuellement (ou encore parce que les locales vont �tre (�ventuellement) perdues...) Et qu'on ne dise pas que ces probl�mes sont r�gl�s sous Debian, lisez les archives r�centes... La recompilation est _LE_ moyen ultime pour ne modifier que ce qui doit l'�tre... (mais cela peut-�tre plus laborieux, certes) Par contre, le syst�me de packaging agit �galement selon le bon vouloir des packageurs (sans critique syst�matique, �videmment). La nuance me semble devoir �tre faite et int�gr�e dans l'esprit d'un utilisateur (avanc� ?) Debian (ou d'un syst�me de paquet qcq) > de tous les build depends existants. Surtout quand le build depends > demande une version sup�rieure � celle dispo dans potato. L� tu n'as > d'autres choix que d'�diter le champ Build-Depends de debian/control. Il me semble que la solution equivs est viable, le paquet � construire pourrait s'appeler "xlibs-dev-dummy", n�cessiterait "xlib6g" (require) pour ne pas �tre install� sur du "vide", fournirait "xlibs-dev", et "conflicterait" avec xlibs-dev (lors d'une �volution r�elle en woody)... Tout �a si j'ai bien compris (globalement) la doc (succincte) ? A+ ah oui, PS : une impression diffuse : il est important que les packageurs/d�veloppeurs (Debian ou autres) se placent d'avantage dans la position de l'utilisateur "terminal" (un d�tail pour l'un n'est pas n�cessairement un d�tail pour l'autre). Plus sp�cifiquement, "s�parer" (par quelques moyens que ce soit, y compris le mail) les uns des autres ne me semble pas profitable... -- # Georges MARIANO # INRETS, 20 rue �lis�e Reclus # 59650 Villeneuve d'Ascq mailto:[EMAIL PROTECTED] # FRANCE. fax: (33) 03 20 43 83 59 # http://www3.inrets.fr/[EMAIL PROTECTED]
