Home Forums Wiki Doc Install Extras Screenshots Source Code Projects Blog Users Groups Register
Glx-Dock / Cairo-Dock List of forums Technical discussions | Discussions techniques Paquets debian: nouvelle division
The latest stable release is the *3.4.0* : How to install it here.
Note: We just switched from BZR to Git on Github! (only to host the code and your future pull requests)
Technical discussions | Discussions techniques

Subjects Author Language Messages Last message
[Locked] Paquets debian: nouvelle division
matttbe Français 13 fabounet [Read]
22 December 2011 à 13:26

matttbe, Monday 05 December 2011 à 14:53


Subscription date : 24 January 2009
Messages : 12573
Hello,

Concernant les paquets debian du dock, je pense que je vais procéder à une nouvelle division.
Pour le core, on aurait:
  • cairo-dock: meta paquet pour installer tout
  • cairo-dock-core: contenant le binaire ainsi que les man pages et les locales avec une dépendance au data et la libgldi3.
  • cairo-dock-data: les data du core (usr/share)
  • libgldi3: contient la lib (3 car le soname est un .3) avec une dépendance au data.
  • libgldi-dev: contient les headers.
Pourquoi cette nouvelle division? Pour respecter les "normes" (debian policy) concernant la lib. De plus, d'autres projets pourraient utiliser libgldi3 indépendamment du dock. De plus, j'en profite pour avoir un support multi-arch!

Concernant les plug-ins, on aurait:
  • cairo-dock-plug-ins: contenant tous les binaires des plug-ins avec une dépendence au core et au plug-ins-data
  • cairo-dock-plug-ins-data: les data (usr/share)
  • cairo-dock-plug-ins-integration: les binaires pour les plug-ins d'integration de bureau (sans dépendance automatique, uniquement aux plug-ins-data et core)
  • cairo-dock-plug-ins-dbus-interface-python: les 4 suivants contiennent uniquement les interfaces pour différents langages et avec des dépendances correctes. Je pensais installer que l'interface python par défaut pour ne pas ajouter trop de dépendances. L'avantage, c'est que l'on respecte la debian-policy avec les bonnes dépendances et que l'on peut avoir du multi-arch pour les plug-ins (uniquement avec les paquets contenant les .so)
  • cairo-dock-plug-ins-dbus-interface-vala: (voir python)
  • cairo-dock-plug-ins-dbus-interface-ruby: (voir python)
  • cairo-dock-plug-ins-dbus-interface-mono: (voir python)

Qu'en pensez-vous? Il y a aussi moyen de scinder les plug-ins (ex: ceux avec des dépendances extras comme weblet, mail, impulse, les "indicators applets", etc.) mais à voir si c'est vraiment utile...

lylambda, Tuesday 06 December 2011 à 12:22


Subscription date : 06 September 2009
Messages : 1635
Tu as l'air d'avoir bien réfléchis à la question
Le fait de suivre la debian policy va permettre de ne plus avoir de problème pour les dépôts Debian ?

Il y a aussi moyen de scinder les plug-ins
À voir le ratio en entre avantages apportés (gain de place, paquets moins volumineux et moins longs à compiler, installer que ce qui est utiliser, etc.) et la charge de travail que cela t'apporte (multiplication des paquets à maintenir notamment).

matttbe, Tuesday 06 December 2011 à 14:26


Subscription date : 24 January 2009
Messages : 12573
Le fait de suivre la debian policy va permettre de ne plus avoir de problème pour les dépôts Debian ?
bonne réflection et je pense bien que... ça ne va rien changer! Enfin, pour le core, p-e mais pour les plug-ins?

Pour les plug-ins, le gros avantage, c'est les dependances auto mais alors, toutes les interfaces ne seront pas installées mais installables facilement (on peut ajouter une ligne pour ça dans la description de l'applet mais ça ne concerne qu'une applet en Ruby et une en vala pour les devs).
À noter que l'on pourrait egalement ajouter des applets third-party en les installant dans /usr/share/cairo-dock/plug-ins/Dbus/ => @fabounet, qu'en penses-tu? Lesquelles ajouter?
Pour la maintenance, c'est deja des cas particuliers et le changement consiste surtout à deplacer 1 ligne par nouveau paquet vers un nouveau fichier et ajouter une description du nouveau paquet.

fabounet, Tuesday 06 December 2011 à 16:28


Subscription date : 30 November 2007
Messages : 17118
je suis pour séparer les interfaces ruby/autres, ça fait des grosses dépendances si on veut respecter les règles.
donc en "recommends" par exemple ?

pour le reste, en tant qu'utilisateur, j'aime bien qu'un paquet ne m'installe pas 36 choses, même si elles sont petites (je n'en sais rien).
c'est psychologique, mais je pense que beaucoup pensent pareil.

séparer la lib c'est bien.
après, faire un paquet "ubuntu indicator", "extras" (dépendances), pourquoi pas mais ils seraient vraiment très petits chacun, et puis il faudra décider lesquels mettre, et ça fait un choix en plus pour l'utilisateur, donc bof

À noter que l'on pourrait egalement ajouter des applets third-party en les installant dans /usr/share/cairo-dock/plug-ins/Dbus/

là encore j'hésite, je trouve ça pas mal de pouvoir choisir ceux qu'on veut installer (mais avec une présentation meilleure que Synaptic, et sans nécessiter les droits root). Finalement, entre activer une applet en conf (ouvrir la config, cocher la case), ou via la page web (ouvrir la page web, drag'n'drop), c'est presque pareil (prévue, description, 1 clic, par contre pas de catégorie dans le 2ème cas il me semble).
si on devait choisir je dirais pidgin, transmission, translator, mais c'est subjectif.
à la limite, je verrais mieux une meilleure catégorisation sur la page web

Edit: merci pour ces paquets au fait ! on peut espérer qu'un jour ils seront utilisés par Debian et Ubuntu (et les autres debian-based), au pire ils seront sûrement très utiles à tous les Debianistes.

matttbe, Wednesday 07 December 2011 à 01:34


Subscription date : 24 January 2009
Messages : 12573
donc en "recommends" par exemple ?
les paquets en 'recommends' sont installés automatiquement par apt, donc j'aurais plus dit l'interface Pÿthon en 'Recommends' et les autres en 'Suggests'.

ça fait un choix en plus pour l'utilisateur
Sauf si on ajoute ces paquets dans les dépendances de 'cairo-dock' (et en 'recommends'-'suggests' pour Debian)

il faudra décider lesquels mettre
C'est surtout ça le problème je pense (sauf si on prend le critère 'dépendance supplémentaires'). Sur Ubuntu, je crois qu'il n'y a que libetpan qui s'installe en plus du dock, ce n'est donc pas vraiment nécessaire de partager les paquets comme ça. Par contre, pour Debian, l'intérêt pourrait être plus grand mais ça ne concerne qu'une minorité de personnes je pense.

Finalement, entre activer une applet en conf (ouvrir la config, cocher la case), ou via la page web (ouvrir la page web, drag'n'drop), c'est presque pareil
Je crois surtout que le panneau de conf est beaucoup plus visible que la page web. Pourquoi pas mieux exploiter le list.conf et ajouter les applets extras dans le panneau de config? ou un panneau de config dédié comme les thèmes?
D'ailleurs, que penses-tu de l'idée d'unifier les différents panneaux de config (à pas le panneau avancé)?

fabounet, Wednesday 07 December 2011 à 13:49


Subscription date : 30 November 2007
Messages : 17118
les paquets en 'recommends' sont installés automatiquement

par défaut, car beaucoup les désactivent

en dépendances supplémentaires, il y'a weblets (webkit, assez lourd), terminal, mail, impulse.
et aussi GMenu, alsamixer, powermanager, mais elles sont trop importantes
donc le critère "dépendance" n'est pas si pertinent, même si ça fait toujours du bien d'alléger.

matttbe, Wednesday 07 December 2011 à 17:23


Subscription date : 24 January 2009
Messages : 12573
les paquets en 'recommends' sont installés automatiquement

par défaut, car beaucoup les désactivent
Oui mais du coup, il faut modifier un fichier de config ou ajouter un paramètre à apt. Mais 'dépendance', ça veut normalement dire "sans ça, ça ne fonctionne pas".

fabounet, Thursday 08 December 2011 à 17:16


Subscription date : 30 November 2007
Messages : 17118
perso, je n'installe quasiment jamais les recommends (et les suggestions sont bien sûr bannis de mon apt ), car beaucoup de programmes y mettent n'importe quoi.
donc si on met des trucs en "recommends", il vaut mieux qu'ils ne soient réellement pas vitaux (l'interface Python étant vitale par exemple, mais par contre certaines applet comme weblets non)
après quant à l'utilité de séparer, je te laisse juge, tu maîtrises mieux les .deb que moi

matttbe, Thursday 08 December 2011 à 17:28


Subscription date : 24 January 2009
Messages : 12573
Pour les séparer, ça ne coûte pas grand chose dans le sens où ça peut aller vite. Mais il faut savoir quoi séparer, ce qui n'est pas très facile.

Pour les recommends, prennons l'exemple d'un éditeur pour le langage LaTeX: texlive et autres lib pour compiler un fichier en LaTeX sont mis en recommends car tu pourrais t'en passer et le programme tourne toujours. Les boutons pour compiler ne vont peut-être pas fonctionner si les recommends ne sont pas installés mais alors c'est un choix de l'utilisateur (qui a peut-être compiler texlive sur le côté).
Par contre, on peut ajouter la dépendance à l'interface python dans le paquet 'cairo-dock' mais en 'recommends' pour les plug-ins.

fabounet, Friday 09 December 2011 à 12:49


Subscription date : 30 November 2007
Messages : 17118
ce qu'il y'a c'est que l'interface python est nécessaire pour faire fonctionner certains plug-ins (les extra), donc en fait c'est plutôt l'interface qui devrait être une dépendance des plug-ins. voila pourquoi ça ne me paraît pas judicieux d'y mettre en recommends
en fait, même si Dbus est une extension du core, il faut le voir comme une partie du core, et l'interface Python (même si c'est une extension de l'extension ) est inclus car utilisée par quasi tous les plug-ins.

en fait, il y'aurait peut-être un paquet "plug-ins(-core)" et un paquet "applets" à faire ?

Edit: en fait on chipote un peu, car 99% des gens vont installer le paquet "cairo-dock" et c'est tout je n'aimerais juste pas donner de mauvaises idées aux packageurs Debian, qui couperaient les paquets en quarks s'ils le pouvaient

matttbe, Friday 09 December 2011 à 14:01


Subscription date : 24 January 2009
Messages : 12573
en fait on chipote un peu, car 99% des gens vont installer le paquet "cairo-dock" et c'est tout
En effet
Et du coup, si les personnes qui n'installe pas le paquet 'cairo-dock', ils peuvent s'amuser à ne pas tout installer s'ils veulent (uniquement le core, uniquement les plug-ins, etc.) mais si ça les amuse

SQP, Sunday 11 December 2011 à 08:44


Subscription date : 03 July 2010
Messages : 1081
Je me demande si ca serait pas le moment d'essayer d'elever le niveau des paquets debian a un niveau acceptable pour eux.
(repartir de leur découpage et améliorer jusqu'a ce que ca nous convienne de facon a avoir la meilleure version possible a faire integrer dans les depots).

Sinon pour la granularité, je crois que le programme ne démarre toujours pas si on n'a pas de plug-in, et que ce message d'erreur ne devrait pas forcer la fermeture du programme pour 2 raisons : le dock pourrait convenir comme simple barre des taches, et moi ca me fait chier pour lancer un terminal qd j'ai plus de dock a la suite d'une maj avec nouveau numero de version.
Que le bouton cancel quitte je comprend, mais le bouton valid devrait laisser le dock survivre

matttbe, Sunday 11 December 2011 à 13:40


Subscription date : 24 January 2009
Messages : 12573
Oui mais justement, nous on calle sur leur decoupage... c'est juste embetant a maintenir (surtout lorsque l'on maintient des paquets pour toutes les versions de Debian et Ubuntu...) et ca ne donne vraiment pas envie d'installer un paquet avec 50 paquets en dependence... Et puis surtout, ça amene bcp de problemes, suffit d'analyser leur paquets (fichiers manquants, mauvaise dependences et descriptions, instabilité aussi (sans parler de leur patch parfois bizarre mais ça c'est autre chose...)

fabounet, Thursday 22 December 2011 à 13:26


Subscription date : 30 November 2007
Messages : 17118

Sinon pour la granularité, je crois que le programme ne démarre toujours pas si on n'a pas de plug-in, et que ce message d'erreur ne devrait pas forcer la fermeture du programme pour 2 raisons : le dock pourrait convenir comme simple barre des taches, et moi ca me fait chier pour lancer un terminal qd j'ai plus de dock a la suite d'une maj avec nouveau numero de version.

c'est un hack pour forcer à installer les plug-ins
car dans les plug-ins, il y'a notamment les vues, les rendus de dialogues, les animations, etc
d'où mon idée de séparer plug-ins "essentiels" et "applets"

Technical discussions | Discussions techniques

Subjects Author Language Messages Last message
[Locked] Paquets debian: nouvelle division
matttbe Français 13 fabounet [Read]
22 December 2011 à 13:26


Glx-Dock / Cairo-Dock List of forums Technical discussions | Discussions techniques Paquets debian: nouvelle division Top

Online users :

Powered by ElementSpeak © 2007 Adrien Pilleboue, 2009-2013 Matthieu Baerts.
Dock based on CSS Dock Menu (Ndesign) with jQuery. Icons by zgegball
Cairo-Dock is a free software under GNU-GPL3 licence. First stable version created by Fabounet.
Many thanks to TuxFamily for the web Hosting and Mav for the domain name.