Après les backports, les forwardports ?
Attention, c'est un peu technique ... mais ça me semble intéressant de partager !
Généralement sous linux quand on a un système stable et qu'on souhaite avoir des applications super récentes on utilise des ... backports.
Par exemple mon ordinateur est avec ubuntu 14.04 (exemple fictif) et je souhaite pouvoir utiliser le logiciel inkscape dans la version qui est proposée sur ubuntu 16.10 ... mais je n'ai pas envie de passer à ubuntu 16.10 (pour x raisons). Je vais donc pouvoir faire un backport du paquet logiciel de inkscape : je prends le code source de la version proposée sur ubuntu 16.10 et je le compile sur ma ubuntu 14.04 ... ça passe (ou pas, parfois ça demande beaucoup de boulot) ... et au final j'ai donc mon système d'exploitation stable et une application plus récente.
Là j'ai maintenant la situation inverse, j'ai une ubuntu 16.04 qui installe en même temps une version de kdenlive qui ne marche pas (les développeurs de kdenlive sont en plein chantier) et je voudrais donc installer une ancienne version (0.9.10) qui marchait bien, celle de ubuntu 14.04 ... je lance donc l'idée de "forwardports" ? aucune idée de savoir si d'autres gens sous linux font la même chose que moi ...
Ce qui est assez drôle quand on fait ce genre de choses c'est de rencontrer ce genre de situation:
kdenlive-0.9.10/src/scopes/abstractscopewidget.cpp:365:29: error: call of overloaded ‘abs(float&)’ is ambiguous
if (abs(diff) > m_rescaleVerticalThreshold || movement.x() == 0) {
^
In file included from /usr/include/c++/6/cstdlib:75:0,
from /usr/include/c++/6/ext/string_conversions.h:41,
from /usr/include/c++/6/bits/basic_string.h:5402,
from /usr/include/c++/6/string:52,
from /usr/include/c++/6/bits/locale_classes.h:40,
from /usr/include/c++/6/bits/ios_base.h:41,
from /usr/include/c++/6/ios:42,
from /usr/include/c++/6/ostream:38,
from /usr/include/c++/6/iterator:64,
from /usr/include/qt4/QtCore/qlist.h:54,
from /usr/include/qt4/QtCore/qobject.h:50,
from /usr/include/qt4/QtGui/qwidget.h:47,
from /usr/include/qt4/QtGui/QWidget:1,
from /home/erics/dev/kdenlive/kdenlive-0.9.10/src/scopes/abstractscopewidget.h:16,
from /home/erics/dev/kdenlive/kdenlive-0.9.10/src/scopes/abstractscopewidget.cpp:11:
/usr/include/stdlib.h:735:12: note: candidate: int abs(int)
extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
Enfin, moi je trouve ça drôle mais il faut être du métier pour apprécier ... en fait la version des fichiers fournis par le compilateur "moderne" de mon système est plus regardant que ceux de la version qui existait à l'époque où le code source de kdenlive 0.9.10 compilait ... c'est ... drôle ... non ? bon ok je sors !
Ça permet de toucher du doigt la notion d'écosystème appliqué au code source: il y a pas un peu de magie mais je trouve que ça s'en approche pas mal pour que tout compile à un instant X ... car 4 ans plus tard si vous n'avez pas exactement les mêmes versions des mêmes outils c'est possible que ça ne compile plus.
Et là encore le fait que ça soit du code libre est à mon sens une force car dans mon cas particulier je peux chercher de la doc et voir que les développeurs du compilateur ont maintenant implémentés une fonction fabs qui fait le boulot sur les float alors qu'a l'époque on s'en foutait un peu ...
Bref, je modifie le code, relance la compilation et ... c'est prêt ! me voici avec un "vieux" (mais stable et que je connaît par cœur, y compris ses bugs) logiciel sur un système "récent" ...
