Re: "support" potato
On Mon, 20 Aug 2001 18:19:08 +0200
Raphael Hertzog <hertzog@debian.org> 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:georges.mariano@inrets.fr
# FRANCE. fax: (33) 03 20 43 83 59
# http://www3.inrets.fr/B@INRETS
Reply to: