Projet

Général

Profil

Anomalie #2821

Impossible d'installer des paquets en 2.3.3 minimum

Ajouté par Emmanuel GARETTE il y a environ 12 ans. Mis à jour il y a presque 10 ans.

Statut:
Classée sans suite
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
03/02/2012
Echéance:
% réalisé:

0%

Temps passé:
Distribution:
EOLE 2.4

Description

Avant la sortie du CD 2.3.3, il y avait deux versions stable d'EOLE 2.3 :

- la version 2.3 minimum avec les dépôts eole-2.3 et eole-2.3-security ;
- la version 2.3 complete avec les dépôts eole-2.3, eole-2.3-security et eole-2.3-updates.

Maintenant qu'une troisième version est ajouté (la version 2.3.3 minimum) et qu'aucun dépôt n'est prévu pour cette version nous arrivons au resultat logique :

Il n'est plus possible d'installer de paquet depuis le réseau !

Pourquoi ? Parce que les dépôts sont configurés sur eole-2.3 et eole-2.3-security qui correspondent à l'état technique 2.3 minimum qui est bien antérieur à l'état technique de la 2.3.3.

Par exemple, si j'installe un eolebase, que je fais :

  1. Query-Auto -i
  2. apt-eole install scribe-pkg

Le résultat attendu est :

Lecture des listes de paquets...
Construction de l'arbre des dépendances...
Lecture des informations d'état...
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :

Les paquets suivants contiennent des dépendances non satisfaites :
scribe-pkg: Dépend: conf-scribe mais ne sera pas installé
E: Paquets défectueux

Il ne peut pas installer Scribe sur un eolebase depuis le réseau.

En même temps, nous avions abandonné l'idée de faire les mises à jour minimum sur la 2.2 à cause de point et nous avions décidé de ne faire de CDs qu'à la synchronisation complete <=> minimum pour éviter ce problème.

Conséquence, toutes les installations réseaux sont à proscrire. Comment faire des installations de paquet depuis Zéphir ? Plus possible. Comment installer un paquet Envole supplémentaire ? Il faut passer par le CD.

D'ailleurs, je me demande comment intégrer cela correctement sur le Zéphir si on a décider d'être en minimum partout (avec potentiellement des versions différentes alors qu'on pense être sur la même version ... minimum).


Demandes liées

Lié à eole-reprepro - Evolution #2973: Créer un projet eole-reprepro Fermé 27/02/2012
Lié à Documentations - Anomalie #3052: Expliquer les mises à jour Ne sera pas résolu 09/03/2012
Lié à Documentations - Evolution #6790: Revoir la documentation sur les mises à jour Fermé

Révisions associées

Révision 56d3fa29 (diff)
Ajouté par moyooo il y a presque 13 ans

prepare auto include in update see #2821

Révision 1ea4014b (diff)
Ajouté par Daniel Dehennin il y a environ 12 ans

Add pull configuration to move packages between distributions.

- distribution testing get packages from -unstable
distribution proposed-updates get packages from -testing
distribution security get packages from -proposed-updates
distribution -updates get packages from -proposed-updates and -security

  • pulls: Add pull rules.
  • distributions (Pull): Use pull rules.

Ref: #2821 @20m

Historique

#1 Mis à jour par Daniel Dehennin il y a environ 12 ans

  • Projet changé de Distribution EOLE à creole

#2 Mis à jour par Daniel Dehennin il y a environ 12 ans

  • Version cible mis à Mises à jour 2.3.4 RC

C’est moche de balancer les paquets depuis -updates dans -security.

4 niveaux de paquets:

  1. Paquets stables : paquets du CD originel + mises à jour de sécurité + mises à jour « stabilisées » et/ou « super importantes » ;
  2. Paquets proposés pour la prochaine mise à jour stable : correction de bug non critiques ;
  3. Paquets à tester : avec de possibles nouvelles fonctionnalités ;
  4. Paquets en développement.

Cela doit s’accompagner d’une utilisation cohérente de git:

  • Paquets sécurité <= utilisation du tag du paquet en production + application d’un patch et ajout d’un '+X' au numéro de version ;
  • Paquets proposés à la prochaine mise à jour stable <= paquets à tester ;
  • Paquets à tester <= paquet en développement
  • Paquets en développement <= branche master.

Merci.

#3 Mis à jour par Emmanuel GARETTE il y a environ 12 ans

Daniel Dehennin a écrit :

C’est moche de balancer les paquets depuis -updates dans -security.

Les noms du dépôt qui n'est pas adaptés, pas le contenu.

4 niveaux de paquets:

  1. Paquets stables : paquets du CD originel + mises à jour de sécurité + mises à jour « stabilisées » et/ou « super importantes » ;
  2. Paquets proposés pour la prochaine mise à jour stable : correction de bug non critiques ;
  3. Paquets à tester : avec de possibles nouvelles fonctionnalités ;
  4. Paquets en développement.

Ces quatres niveaux n'existent pas aujourd'hui. Je ne vois pas bien comment tu veux insérer cela dans la distribution 2.3. En tout je pense que cela mérite discussion.

Aujourd'hui nous avons :

  1. mise à jour minimum ;
  2. mise à jour complète ;
  3. mise à jour proposed ;
  4. mise à jour développement.

#4 Mis à jour par Daniel Dehennin il y a environ 12 ans

Emmanuel GARETTE a écrit :

Daniel Dehennin a écrit :

C’est moche de balancer les paquets depuis -updates dans -security.

Les noms du dépôt qui n'est pas adaptés, pas le contenu.

Tout à fait, c’est moche.

Ces quatres niveaux n'existent pas aujourd'hui. Je ne vois pas bien comment tu veux insérer cela dans la distribution 2.3. En tout je pense que cela mérite discussion.

Aujourd'hui nous avons :

  1. mise à jour minimum ;
  2. mise à jour complète ;
  3. mise à jour proposed ;
  4. mise à jour développement.

Ho c’est rigolo, on retrouve 4 niveaux ;-)

Mon idée de base était de conserver la méthode mais intégrer le dépôt -updates dans dans la mise à jour « minimum ».

Pour la mise en pratique il faut attendre une « synchro » « -updates => -security » et modifier Query-Auto.

#5 Mis à jour par Emmanuel GARETTE il y a environ 12 ans

Daniel Dehennin a écrit :

  1. mise à jour minimum ;
  2. mise à jour complète ;
  3. mise à jour proposed ;
  4. mise à jour développement.

Ho c’est rigolo, on retrouve 4 niveaux ;-)

Sauf que ces 4 niveaux ne correspondent pas à tes 4 niveaux.

Mon idée de base était de conserver la méthode mais intégrer le dépôt -updates dans dans la mise à jour « minimum ».

Pour la mise en pratique il faut attendre une « synchro » « -updates => -security » et modifier Query-Auto.

Donc minimum == complete (les dépôts devenant identique.

#6 Mis à jour par Joël Cuissinat il y a environ 12 ans

  • Statut changé de Nouveau à En attente d'informations
  • Assigné à mis à Daniel Dehennin
  • % réalisé changé de 0 à 80

Résolu par : http://dev-eole.ac-dijon.fr/news/87

Mais en attente de nouvelles solutions pour le futur :)

#7 Mis à jour par Daniel Dehennin il y a environ 12 ans

  • Version cible changé de Mises à jour 2.3.4 RC à Eole 2.4-dev-1
  • % réalisé changé de 80 à 0
  • Distribution changé de EOLE 2.3 à EOLE 2.4

Que penser de cette idée:

  • Un dépôt à usage uniquement des développeurs: si un développeur ajoute ce dépôt à un serveur, c’est uniquement pour installer un paquet (pas de Maj-Auto possible) (dépôt en -experimental)
  • Un dépôt d’intégration entre tous les développeurs: point d’entrée par défaut de toute nouvelle compilation (dépôt en -unstable)
  • Un dépôt pour test par les utilisateurs, à ne pas mettre en production, les paquets n’arrivent dans ce dépôt que depuis le dépôt ci-dessus (dépôt en -testing)
  • Un dépôt contenant des paquets stables proposés pour la prochaine mise à jour « lourde », ces paquets inclus de nouvelles fonctionnalitées (dépôt en -proposed-updates)
  • Un dépôt contenant les mises à jours lourdes diffusées aux utilisateurs en version stable (dépôt en -updates)
  • Un dépôt contenant les mises à jours prioritaires ne pouvant attendre la prochaine mise à jour lourde (dépôt en -security)
  • Un dépôt de base contenant les paquets de la première release

#8 Mis à jour par Daniel Dehennin il y a environ 12 ans

J’ai oublié de préciser qu’il n’y a que deux points d’entrées pour un paquet :

  1. Un « slow path » par le dépôt -unstable utilisable par tout le monde ;
  2. Un « fast path » par le dépôt -security dont l’utilisation devrait être sérieusement encardrée.

#9 Mis à jour par Joël Cuissinat il y a environ 11 ans

  • Version cible changé de Eole 2.4-dev-1 à 189

#10 Mis à jour par Joël Cuissinat il y a presque 10 ans

  • Statut changé de En attente d'informations à Classée sans suite
  • Version cible 189 supprimé

Formats disponibles : Atom PDF