Oui, je parle du build service.
Pour moi cela pourrait permettre aux mainteneurs de distribs' et à l'upstream de dialoguer plus facilement :
- fourniture plus facile de toutes les traces de compil'
- possible implication de l'upstream dans plus de distributions (évite le "coût" initial d'installation de multiples distribution), permet de voir ce que ça donne sur une autre distrib' que la sienne et permet même de travailler ;-) même si cela se restreint à la compil' / packaging c'est pas mal
bon il ne faudrait pas que ça se transforme en ferme à backports personnels, mais si ça peut contribuer à travailler à plus nombreux sur le packaging de certains paquets, c'est pas mal. C'est surtout sur le volet applications que cela peut être pratique (pas trop de dépendances) àmha. Pour des mises à jour de gcc mieux vaut avoir une synchro un peu plus importante.
Pour dkms, je notais le point de deux points de vue :
- en terme de découpage du kernel : ajout de pilotes non encore inclus au kernel (c'est l'utilisation "standard"), ajout de versions de pilotes inclus dans kernel suivant
- en terme de packaging, un gros paquet kernel d'un côté, des petits paquets à côté, avec la contrainte que le gcc ne bouge pas entre les deux
dans certains cas (l'exemple donné), cela permet de découpler et de ne pas se trimballer une "grosse" version de kernel
[^] # Re: synchro ou suivre ou avancer
Posté par BAud (site web personnel) . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Pour moi cela pourrait permettre aux mainteneurs de distribs' et à l'upstream de dialoguer plus facilement :
- fourniture plus facile de toutes les traces de compil'
- possible implication de l'upstream dans plus de distributions (évite le "coût" initial d'installation de multiples distribution), permet de voir ce que ça donne sur une autre distrib' que la sienne et permet même de travailler ;-) même si cela se restreint à la compil' / packaging c'est pas mal
bon il ne faudrait pas que ça se transforme en ferme à backports personnels, mais si ça peut contribuer à travailler à plus nombreux sur le packaging de certains paquets, c'est pas mal. C'est surtout sur le volet applications que cela peut être pratique (pas trop de dépendances) àmha. Pour des mises à jour de gcc mieux vaut avoir une synchro un peu plus importante.
Pour dkms, je notais le point de deux points de vue :
- en terme de découpage du kernel : ajout de pilotes non encore inclus au kernel (c'est l'utilisation "standard"), ajout de versions de pilotes inclus dans kernel suivant
- en terme de packaging, un gros paquet kernel d'un côté, des petits paquets à côté, avec la contrainte que le gcc ne bouge pas entre les deux
dans certains cas (l'exemple donné), cela permet de découpler et de ne pas se trimballer une "grosse" version de kernel