Modifier les dependances d’un paquet Debian

Quand on installe des paquets provenant de sources non officielles, il arrive fréquemment que les dépendances déclarées dans les paquets ne correspondent pas au système sur lequel on installe ces paquets.

C’est le cas par exemple lorsque l’on installe la version courante d’Opera sur Ubuntu 5.10 « BreezyBadger » ou celle de Skype sur Ubunto 5.04 « HoaryHedgehog » :

vdv@vaio:~ $  sudo dpkg -i /opt/downloads/skype_1.2.0.17-1_i386.deb
Password:
(Lecture de la base de données... 169348 fichiers et répertoires déjà installés.)
Préparation du remplacement de skype 1.2.0.17-1 (en utilisant .../skype_1.2.0.17-1_i386.deb) ...
Dépaquetage de la mise à jour de skype ...
dpkg : des problèmes de dépendances empêchent la configuration de skype :
 skype dépend de libqt3c102-mt (>= 3:3.3.3.2) ; cependant :
  La version de libqt3c102-mt sur le système est 3:3.3.3-7ubuntu3.
dpkg : erreur de traitement de skype (--install) :
 problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
 skype

Face à ce type de solution, on peut forcer l’installation avec l’option « –force » :

vdv@vaio:~ $  sudo dpkg --force depends -i /opt/downloads/skype_1.2.0.17-1_i386.deb
Password:
(Lecture de la base de données... 169348 fichiers et répertoires déjà installés.)
Préparation du remplacement de skype 1.2.0.17-1 (en utilisant .../skype_1.2.0.17-1_i386.deb) ...
Dépaquetage de la mise à jour de skype ...
dpkg : skype : problèmes de dépendances, mais configuration comme demandé :
 skype dépend de libqt3c102-mt (>= 3:3.3.3.2) ; cependant :
  La version de libqt3c102-mt sur le système est 3:3.3.3-7ubuntu3.
Paramétrage de skype (1.2.0.17-1) ...

        

Cela permet de tester l’application et de vérifier qu’elle fonctionne sur votre système, mais le paquet est considéré être « cassé » et le système ne se prive pas de vous le rappeler :

vdv@vaio:~ $ sudo apt-get dist-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Vous pouvez lancer « apt-get -f install » pour corriger ces problèmes.
Les paquets suivants contiennent des dépendances non satisfaites :
  skype: Dépend: libqt3c102-mt (>= 3:3.3.3.2) mais 3:3.3.3-7ubuntu3 est installé
E: Dépendances manquantes. Essayez d'utiliser l'option -f.
            

Si vous essayez « apt-get -f install », celui-ci propose de désinstaller le paquet récalcitrant et on est revenu au point de départ:

vdv@vaio:~ $ sudo apt-get -f install
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Correction des dépendances... Fait
Les paquets suivants seront ENLEVÉS :
  skype
0 mis à jour, 0 nouvellement installés, 1 à enlever et 3 non mis à jour.
Il est nécessaire de prendre 0o dans les archives.
Après dépaquetage, 9160ko d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? n
Annulation.
            

Une solution à ce problème est de corriger les dépendances dans le paquet lui-même, ce qui est beaucoup plus facile qu’on ne pourrait le redouter…

Il faut pour cela extraire les fichiers du paquet :

vdv@vaio:~ $ cd /tmp
vdv@vaio:/tmp $ dpkg-deb -x /opt/downloads/skype_1.2.0.17-1_i386.deb skype_1.2.0.17-1_i386
            

Cette commande n’extrait pas le fichiers de contrôle qu’il faut extraire dans un deuxième temps :

vdv@vaio:/tmp $ mkdir skype_1.2.0.17-1_i386/DEBIAN
vdv@vaio:/tmp $ dpkg-deb -e /opt/downloads/skype_1.2.0.17-1_i386.deb skype_1.2.0.17-1_i386/DEBIAN
            

On peut maintenant éditer le fichier de contrôle :

vdv@vaio:/tmp $ gvim skype_1.2.0.17-1_i386/DEBIAN/control
            

Pour modifier le numéro de version dans la ligne :

Depends: libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.4.1-3), libqt3c102-mt (>= 3:3.3.3.2), libstdc++5 (>= 1:3.3.4-1), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0)
            

Par celui de notre installation :

Depends: libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.4.1-3), libqt3c102-mt (>= 3:3.3.3-7ubuntu3), libstdc++5 (>= 1:3.3.4-1), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0)

Il suffit maintenant de reconstituer le paquet :

vdv@vaio:/tmp $ dpkg-deb -b skype_1.2.0.17-1_i386
dpkg-deb : construction du paquet « skype » dans « skype_1.2.0.17-1_i386.deb ».
            

Et de le réinstaller :

vdv@vaio:/tmp $ sudo dpkg -i skype_1.2.0.17-1_i386.deb
(Lecture de la base de données... 169348 fichiers et répertoires déjà installés.)
Préparation du remplacement de skype 1.2.0.17-1 (en utilisant skype_1.2.0.17-1_i386.deb) ...
Dépaquetage de la mise à jour de skype ...
Paramétrage de skype (1.2.0.17-1) ...

Bien entendu, cela ne fonctionne que si le problème de dépendances était fictif, d’où l’utilité de tester cela avec la commande « dpkg –force depends » avant d’entreprendre l’opération, mais lorsque c’est le cas, cette manipulation assez simple règle le problème de manière définitive… jusqu’à la prochaine version!

TreeBind: one infoset to bind them all

This is the first entry of a series dedicated to the TreeBind generic binding API.
I have recently made good progress in the extensive refactoring of TreeBind required by my proposal to support RDF and it’s time to start explaining these changes.

The first of them is the infoset on which TreeBind is now relying.

TreeBind’s target is to propose and implement a binding mechanism that can support XML, Java objects but also RDF and LDAP (my new implementation includes support for these two models as data sources) and, potentially, other sources such as relational databases or even PSVIs…

In order to cover all these data sources, TreeBind required an infoset (or data model) which is a superset of the data models of these sources.

The new TreeBind infoset is simple enough to cope with all these data models. It consists in:

  • Names. These different sources have different ways of defining names. Names can include both a domain name and a local name (that’s the case with XML and namespaces, but also with Java Class names and packages), they can include only a local name (that’s the case with LDAP but also for Java method names) or can be more complex like XML attribute names in which the namespace of the parent element has a role to play.
  • Complex properties. These are non leaf properties. Complex properties have a nature which is a name and a set of embedded properties that are either complex or leaf properties. When a sub property is attached to a property, the attachment carries a role which is a name.
  • Leaf properties. Leaf properties have a nature (which is a name) and a value.

That’s all…

This is enough to differentiate, for instance, an XML element from an XML attribute because their names belong to different name classes.

This would, potentially, allow to cope with mixed content by adding a new class of names to support text nodes. This is not implemented for the moment, just because I don’t have any business case to justify the additional workload.

If needed, the same could be done to support other XML constructions such as PIs and comments.

A concept which is clearly missing and should probably be added in a future version is the concept of identity.

Names are used to identify the nature of the objects and the roles they play in the different associations.

When we use TreeBind to bind not only trees but also graphs (which is the case of RDF, LDAP and even XML if we want to support some type of id/idref), we need to be able to identify objects in order to avoid creating binding loops.

This could be done by attaching an ID which could also be a name to each property.

So what?

The new version of TreeBind is implementing a SAX like paradigm built on top of this simple infoset like SAX is (more or less) built on top of the XML infoset.

Binding a source to a sink is done by implementing or just using:

  • A source that will read the data source and stream properties.
  • A sink that receives streamed properties and create the target data.
  • One or more filters to deal with the impedance mismatches between the source and the sink.

The strength of this architecture is that if the built-in pipe that does the binding is not flexible enough for your application, you can just add a filter that will cope with your specific requirements.

We’ll explore all that in more details in the next entries…

Using Orbeon PresentationServer with a recent version of eXist

Why would you want to do that?

Orbeon PresentationServer is currently shipping with eXist 1.0 beta2.

This is true of both OPS version 2.8 (the current stable release) and OPS 3.0 beta 3 (the latest beta of the next generation).

While eXist 1.0 beta2 is described as the stable version of the Open source XML database, their web site displays the following Health Warning:

The 1.0 beta2 release is truly ancient now. There were lots of bug fixes and feature enhancements during the past months, so using beta2 cannot be recommended any more. Please download a newer development snapshot. Recent development snapshots can be regarded as stable. A new official « stable » release is in preparation, but as usual, we lack the time to complete the documentation. Any help will be welcome!

Among the many enhancements included in more recent versions, Transactions and Crash Recovery is very worth mentioning:

After several months of development, eXist does now support full crash recovery. Crash recovery means that the database can automatically recover from an unclean termination, e.g. caused by a killed jvm, power loss, system reboot or hanging processes.

This might be a reason of the corruptions noticed in my experience with OPS and eXist and that has been my motivation to migrate http://apiculteurs.info to the latest eXist snapshot

While this is not rocket science, the following notes may help you if you want to attempt the same migration.

Environment

My environment is Ubuntu Hoary, Java Sun j2sdk 1.4 and /or 1.5, Jetty and OPS 2.8 but the same procedure should be valid for other environments.

Migration

Database backup

The physical database format has changed between these versions and, if you have to keep a database during this migration, you need to backup the database using the eXist client before starting the actual migration.

I’ll cover how to use the eXist client with an eXist database embedded in OPS in a future blog entry, in the mean time, you can refer to this thread of the ops-users mailing list.

After you’ve done this backup, remove the content of the old database:

rm orbeon/WEB-INF/exist-data/*

Removing the old libraries

You should then stop your servlet and move to the orbeon « orbeon/WEB-INF/lib » directory where you’ll find four eXist libraries:

orbeon/WEB-INF/lib/exist-1_0b2_build_1107.jar
orbeon/WEB-INF/lib/exist-optional-1_0b2_build_1107.jar
orbeon/WEB-INF/lib/xmldb-exist_1_0b2_build_1107.jar
orbeon/WEB-INF/lib/xmlrpc-1_2_patched_exist_1_0b2_build_1107.jar
            

Remove these four libraries from « orbeon/WEB-INF/lib » and keep them somewhere else in case you want to move back to eXist 1.0 beta2 later on.

Installing the eXist snapshot

Install the eXist snapshot through:

java -jar eXist-snapshot-20050805.jar

Choose whatever directory you want to install this new version but keep it out of the scope of your OPS install: we are doing this installation only to get the new libraries!

Installing the new libraries

You need to copy five eXist libraries into « orbeon/WEB-INF/lib ». If you’ve install eXist in « /opt/eXist », move to « orbeon/WEB-INF/lib » and type:

cp /opt/eXist/exist.jar eXist-snapshot-20050805.jar
cp /opt/eXist/exist-optional.jar exist-optional-snapshot-20050805.jar
cp /opt/eXist/exist-modules.jar exist-modules-snapshot-20050805.jar
cp /opt/eXist/lib/core/xmldb.jar xmldb-eXist-snapshot-20050805.jar
cp /opt/eXist/lib/core/xmlrpc-1.2-patched.jar xmlrpc-1.2-patched-eXist-snapshot-20050805.jar
            

Move to java 5.0

eXist now relies on some Java 5.0 classes and if you try to use it with j2sdk 1.4, you’ll run into errors such as:

22:37:11.168 WARN!! [SocketListener0-9] org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:574) >11> Error for /orbeon/apiculteurs/administration/statistiques/montre
java.lang.NoClassDefFoundError: javax/xml/datatype/DatatypeConfigurationException
	at org.exist.xquery.value.AbstractDateTimeValue.<clinit>(AbstractDateTimeValue.java:157)
	at org.exist.xquery.functions.FunCurrentDateTime.eval(FunCurrentDateTime.java:51)
	at org.exist.xquery.PathExpr.eval(PathExpr.java:144)
	at org.exist.xquery.EnclosedExpr.eval(EnclosedExpr.java:58)
	at org.exist.xquery.PathExpr.eval(PathExpr.java:144)
	at org.exist.xquery.ElementConstructor.eval(ElementConstructor.java:173)
	at org.exist.xquery.AbstractExpression.eval(AbstractExpression.java:43)
	at org.exist.xquery.PathExpr.eval(PathExpr.java:159)
            

To fix that, the simplest solution (assuming your application supports it) is to move your servlet to j2sdk 1.5.

Restart, restore and enjoy

You’re almost done!

Restart your servlet, restore your database using the eXist client and enjoy your brand new eXist installation.

After a servlet reload, in the servlet log, you’ll notice new messages:

            2005-10-07 08:51:08,615 INFO  org.exist.storage.XQueryPool null - QueryPool: maxStackSize = 5; timeout = 120000; timeoutCheckInterval = 30000
Scanning journal  [==                                                ] (4 %)
Scanning journal  [====                                              ] (8 %)
Scanning journal  [======                                            ] (12 %)
Scanning journal  [========                                          ] (16 %)
Scanning journal  [==========                                        ] (20 %)
Scanning journal  [=================                                 ] (34 %)
Scanning journal  [====================                              ] (40 %)
Scanning journal  [==============================                    ] (60 %)
Scanning journal  [========================================          ] (80 %)
            2005-10-07 08:51:19,713 INFO  org.orbeon.oxf.pipeline.InitUtils null - /apicu

These messages confirm that your eXist installation is now using a journal.