Différentes versions du même paquet Debian

11

Existe-t-il un moyen d'obtenir des différences de source entre un package installé localement et son package mis à jour? Cela sera utile pour vérifier exactement quelles pièces ont été corrigées, modifiées ou ajoutées.

Par exemple, supposons que le package linux-libc-dev soit installé sur votre système et

sudo apt-get update && sudo apt-get upgrade

spectacles

The following packages will be upgraded:
  linux-libc-dev

mais vous souhaitez vérifier, avant de le mettre à niveau, les modifications exactes qui ont été apportées par rapport à votre version locale du même package.

Comment pouvons-nous le faire?

package-management development motu

— Gödel
source

5

Voici une autre solution que j'ai piratée ensemble: ce qui a changé .

Il prend le nom du package binaire qui vous intéresse comme seul argument. Pour utiliser une SRU récente comme exemple:

./whatchanged python_papyon

Voilà ce que cela fait:

Vérifiez s'il y a un candidat de mise à jour; sortir s'il n'y en a pas
Si un candidat existe, créez des répertoires temporaires et récupérez-y les packages source pour la version installée et le candidat
Comparez les deux avec debdiffet sortie vers stdout (vous voudrez probablement rediriger pour une lecture plus facile)
Nettoyez les répertoires temporaires.

Il doit probablement mieux gérer certaines choses qui peuvent mal se passer lors de la récupération de la source, le contrôle de flux est probablement un peu désactivé et il doit y avoir des moyens plus élégants pour la vérification de la version, mais cela a bien fonctionné jusqu'à présent dans mes tests limités. Pour l'instant, considérez-le comme un hack rapide qui fonctionne, et les améliorations sont les bienvenues. Je vais le pousser vers un dépôt bzr et / ou créer un projet Launchpad s'il est utile à quelques personnes.

Edit : Plutôt que de le laisser pourrir sur pastebin, j'ai commencé un projet Launchpad pour cela; vous pouvez obtenir la dernière révision du tronc avec bzr branch lp:whatchanged. N'hésitez pas à signaler des bugs, à les ramifier, à les réécrire en Perl, etc.

— mgunes
source

Comme c'est gentil! Développer des outils comme réponses;) Comme vous le style de codage, mais l'aurait correctement codé en perl ..

— LassePoulsen

Merci; j'espère que c'est utile. La façon dont l'emballage et les techniques de publication rendent parfois le code ouvert opaque est quelque chose qui m'est venu à l'esprit, et je n'ai pas trouvé d'outils simples pour surmonter cela, donc quelqu'un exprimant un besoin de la même chose était une bonne motivation pour finalement en faire moi-même un primitif.

— mgunes du

7

Afaik la seule façon de le faire est d'obtenir la source et de faire soi-même la différence. Vous pouvez obtenir la source réelle utilisée pour compiler les packages avec apt-get. fx:

apt-get source gwibber=2.30.2-0ubuntu3 gwibber=2.30.0.1-0ubuntu1
diff -rupN gwibber-2.30.0.1/ gwibber-2.30.2/

Cela imprimera toutes les différences entre tous les fichiers dans un format de correctif standard.

— LassePoulsen
source

1

C'est plutôt bien. La seule chose que je changerais dans l'exemple est d'utiliser "debdiff gwibber_2.30.0.1-0ubuntu1.dsc gwibber_2.30.2-0ubuntu3.dsc" plutôt que le diff brut.

— RAOF

1

Eh bien, cela fait pratiquement la même chose, mais vous pouvez utiliser diff sur chaque paquet / tarball là-bas. Peut-être que quelqu'un veut voir la différence entre un tronc svn et le paquetage actuel.

— LassePoulsen

Ma deuxième réponse (ce qui a changé) automatise essentiellement cela.

— mgunes

2

Voici une manière UDD (probablement pas optimale) de le faire:

Pull -updates branche pour votre version (en supposant Lucid) qui (supposition ci-dessous) doit contenir la dernière SRU:

bzr branch lp:ubuntu/lucid-updates/package_name

Obtenez les modifications introduites par la dernière révision, qui (hypothèse ci-dessous) devrait correspondre à la dernière SRU:

bzr diff -c`bzr revno`

— mgunes
source

2

Hmm. C'est une prise intéressante, bien qu'elle soit probablement moins complète que Source Lab dans le sens où les noms des packages peuvent ne pas correspondre, ou exister dans, l'arborescence source bzr.

— Gödel

Tant que vous connaissez le nom du package source, il correspondra. Vous pouvez trouver le paquet source avec lequel un paquet binaire est produit apt-cache show package_name | grep Source:.

— mgunes

@Murat Eh bien, <package_name>ainsi obtenu ne fonctionne pas sur certains packages: bzr branch lp:ubuntu/lucid-updates/$(apt-cache show linux-libc-dev | grep -m 1 Source: | awk "{print \$2}")=> bzr: ERREUR: URL non valide fournie pour le transport: "bzr + ssh: //bazaar.launchpad.net/+branch/ubuntu/lucid-updates/linux" : aucun programme pris en charge

— Gödel

C'est parce qu'il n'y a aucune branche Ubuntu pour le noyau, j'ai bien peur. Cela pourrait être une exception spécifique en raison du fait que le noyau est maintenu dans git (kernel.ubuntu.com) mais je ne suis pas sûr de la portée exacte des branches du paquetage bzr pour le moment. Vous pouvez demander sur # ubuntu-devel.

— mgunes

@Mural je sais. C'est pourquoi la méthode est moins complète que celle de Source Lab. Mais encore une fois, c'est une prise intéressante.

— Gödel

0

Si vous souhaitez voir les différences de fichiers dans les archives du package, extrayez leurs fichiers md5sums, triez et différez-les, puis vous pouvez restreindre la liste des fichiers réels à comparer de manière spectaculaire.

— Phil Miller
source

-1

Il ne s'agit peut-être pas des modifications "exactes", mais apt-listchangesrépertorie les entrées du journal des modifications pour les modifications apportées depuis la version installée.

Il fonctionne en ajoutant une étape après avoir terminé de télécharger les nouveaux packages, mais avant le début de l'installation, où il vous montre l'entrée du journal des modifications pour chaque package sur le point d'être mis à niveau. Vous pouvez ensuite continuer ou annuler. Vous pouvez l'installer avec

sudo apt-get install apt-listchanges

puis configurez-le avec

sudo dpkg-reconfigure apt-listchanges

— Ken Simon
source

Encore une fois, la question n'est pas de montrer les changements ChangeLog.

— Gödel

D'oh, vous avez raté la première ligne où vous avez dit "source diffs".

— Ken Simon