5. Du code à son installation en passant par le packaging :
reproductible à n'importe quel moment
maintenable dans le temps car le contenu est
parfaitement connu
traçable quel que soit le moment : d'où ça vient, qui l'a
modifié, qui a reverté...
sécurisé : le contenu est généré dans un environnement
connu et reproductible
#2 Unechaînedeproductioncomplète
7. #3 git :pourquoi ?
rapide (opérations locales)
design simple
support optimal de la gestion des branches multiples
système complètement distribué (backups data)
sécurisation des données (checksum systématique)
staging de données
système capable de gérer de gros projets en matière de
données et de rapidité
11. #4 Packaging :cequ’onenpensesouvent
Réservé aux packagers des distributions Linux
Pénible et sans intérêt
Une bonne occasion de multiplier les bugs
Une perte de temps
Le meilleur moyen de devoir se plonger dans les
« subtilités » des distributions
13. #4 Packaging :cequirendfouunpackager
des librairies et autres dépendances embarquées dans les tarballs
et qui se terminent en conflit
des librairies harcodées sur une architecture
des problèmes de licenses, différentes selon les composants
des binaires embarqués (plate-forme, sécurité, bugs)
des dépendances téléchargées lors de l'installation (pas de
connaissance exhaustive du contenu, conflits)
hardcodage des spécificités des distributions : initiscripts,
chemins...
15. #4 Packaging :cequeçaapporteréellement
integration parfaite dans une distribution Linux
facilité d’utilisation pour l'utilisateur final : gestion des
dépendances , installation, mise à jour, suppression
facilitation de la diffusion du logiciel
traçabilité des versions et des fichiers installés sur un
système
faciliter la recompilation du logiciel (moyennant les
évolutions des outils comme autotools)
16. #4 Packaging :quiestconcerné ?
les développeurs qui contribuent à fournir un code
facilitant le packaging
les entreprises qui utilisent un socle Linux pour leur
infrastructure interne et qui modifient certains composants
ou les personnalisent
les entreprises qui éditent une solution basée sur un OS
Linux
17. #4 Packaging :lespolitiquesdepackaging
non elles n’ont pas été écrites pour satisfaire un besoin
sadique des packagers officiels des distributions !
elles sont le garant de la cohérence d’une distribution à un
moment donné et dans le temps
18. #4 Packaging :qualitéetoutils
vérification de la concordance des packages aux politiques
(ex : rpmlint, lintian)
vérification de la signature des tarballs sources et des
packages
vérification de la cohérence des dépots de packages
vérification de la qualité des changelogs
20. #4 Packaging :faciliterlaviedesadministrateurssystème
limite les dépendances requises (pas de dépendances de build)
gère les dépendances automatiquement
facilite les mises à jour, investissement moindre une fois le premier
package réalisé
gestion de patches traçable
conserve un historique des modifications
connaissance détaillée des logiciels installés et de leurs versions
21. #4 Packaging :conseilpourlesdéveloppeurs
fournir un script d’installation qui sera utilisé lors du build
du package
Fournir la possibilité overrider la destination d'installation
du logiciel sous peine de patch systématique
Vérifier l’existence des librairies et/ou dépendances
embarquées
Porter une attention particulière à la réalisation du tarball
de sources et à son versioning