[Linux-bruxelles] linux ppc?
Frederic Peters
fpeters at theridion.com
Jeu 4 Avr 14:44:21 CEST 2002
J'écrivais:
> >Et si tu parlais de potato:
> > - i386: 3893
> > - powerpc: 3610
> >
> >Ce qui représente quand même 92%
Et Jens répondait:
> chez moi sur un i386 :
> (...)
>
> 4415 - 4008 = 407
>
> ca relativise la relation de 92 % d'available en 90 % (ou ex negativo
> : 10 % unavailable) -- c'est evidamment super bien. mais en
Les 2% que tu perds viennent de l'addition des packages sortant de
non-free; packages dont il n'est parfois/souvent pas disponible les
sources. Dur, dur de recompiler pour PowerPC dans ces conditions :)
> considerant que deja sous intel potato il manque quelques paquets et
> je pense pas a openoffice mais plutot a la maniere dont certain
> packages sont configure : php4 sans jpeg dans potato, pas de smtp
> auth pour exim dans potato, etc, le ppc port souffre d'avantage.
Les packages sont les _mêmes_ d'une architecture à l'autre.
> donc on doit passer par les tar.gzs et installer ce qu'on prefere en
> plus ou differament. tout en perdant evidamment l'avantage des
> updates par debian-security et la stabilite ...
Ça nous écarte du problème du synchronisme des architectures vers la
bonne vieille discussion "la sortie de nouvelles versions Debian est
lente".
> je comprend et estime beaucoup la politique de stabilite de la debian
> stable. mais il y a des choses qui peuvent etre ameliores : plus de
Des choses qui peuvent être améliorées ? Mais non, tout est parfait :)
> renseignements sur les built-time options employe par le maintainer,
apt-get source package; à côté de ça, le mainteneur peut remplir un
README.Debian avec ces infos mais ce n'est pas obligatoire/utile.
> les changelogs sont parfois tres pauvre en contenu. plus de diversite
Concernant les changelog, j'ai l'impression que dans l'ensemble, ça
s'améliore petit à petit.
Ex: avant:
ethereal (0.5.0-2) unstable; urgency=low
* Fixed package building (Bug#30110)
-- Frederic Peters <fpeters at debian.org> Thu, 3 Dec 1998 13:15:53 +0100
maintenant:
ethereal (0.9.2-3) unstable; urgency=low
* debian/rules: fixed typo that could have caused snmp not to be built.
(closes: #140147) This would happen if 1) built from the CVS tree and 2)
built on a system without libsnmp-dev ("impossible" since we build-depend
on it). Anyway it is fixed for correctness.
-- Frederic Peters <fpeters at debian.org> Wed, 27 Mar 2002 14:00:31 +0100
> dans les packages proposes, peut-etre avec le systeme alternatives ou
> plusieurs packages du meme logiciel (c'est pas tellement plus de
> gestion si ce sont les memes sources et certains maintainer le font
> deja ...).
C'est _beaucoup_ plus de gestion. Et ça alourdirait énormément les
mirrors. Exemple: si au lieu d'avoir ethereal, on avait le choix entre
ethereal, ethereal-ssl, ethereal-snmp et ethereal-snmp-ssl (ce qui m'a
été proposé). On passe de 1,25M à 5M: oh c'est rien. D'accord. Mais
c'est à multiplier par le nombre d'architecture.
L'archive actuelle (woody et sid, uniquement main, ni contrib, ni non-free)
fait 34G. Une augmentation moyenne de 50% et on arrive à 51 qui est ok
pour du pastis mais peut-être un peu lourd pour être mirroré
partout...
La solution actuelle, c'est que le mainteneur décide, en son âme et
conscience, des options utilisées pour la compilation. Et cela donne
_un_ package.
Et les personnes pour qui ça ne convient pas ? On les oublie ? Et
bien même pas... Il est maintenant suggéré aux mainteneurs de
permettre d'une manière standard aux utilisateurs de recréer les
packages avec des options de compilation différentes.
> un serveur potato roule au moment ou on installe quelques tar.gz
> soi-meme mais sur un desktop potato c'est dur a garder -- toi tu
> semble deja avoir fait le mouvement vers woody en tout les cas.
Depuis un bon bout de temps d'ailleurs. Mais ça demande vigilence
constante...
> tiens woody semble presque fini ... on s'apprete de la lancer, non ?
[NON]
Frédéric
--
Frédéric Péters <fpeters at theridion.com> <fpeters at debian.org>
Théridion, spécialistes GNU/Linux, rue de l'Aqueduc 83 - 1050 Bruxelles
GPG: 1024D/6783ED5E: 62BF 2EDA 404A 6EB4 F5BE A1E2 A11D CBB1 6783 ED5E
Plus d'informations sur la liste de diffusion Linux-bruxelles