Je peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépenda nces non
satisfaites, ça risque d'être un peu galère.
Je peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépenda nces non
satisfaites, ça risque d'être un peu galère.
Je peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépenda nces non
satisfaites, ça risque d'être un peu galère.
J'aimerai savoir si les mises à jours des dépôts de sid so nt effectués
de façon régulière et est ce qu'il y a des moments particu lier dans la
journées où il est plus recommander d'effectuer des mises à jours de
son système ?
Je peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépenda nces
non satisfaites, ça risque d'être un peu galère.
J'aimerai savoir si les mises à jours des dépôts de sid so nt effectués
de façon régulière et est ce qu'il y a des moments particu lier dans la
journées où il est plus recommander d'effectuer des mises à jours de
son système ?
Je peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépenda nces
non satisfaites, ça risque d'être un peu galère.
J'aimerai savoir si les mises à jours des dépôts de sid so nt effectués
de façon régulière et est ce qu'il y a des moments particu lier dans la
journées où il est plus recommander d'effectuer des mises à jours de
son système ?
Je peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépenda nces
non satisfaites, ça risque d'être un peu galère.
On Wed, 08 May 2013 18:05:08 +0200
Goldy wrote:
> J'aimerai savoir si les mises à jours des dépôts de sid
> sont effectués de façon régulière et est ce qu'il y a des
> moments particulier dans la journées où il est plus
> recommander d'effectuer des mises à jours de son système ?
Il y a plusieurs MÃ J/24H.
[â¦]
On Wed, 08 May 2013 18:05:08 +0200
Goldy <goldy@goldenfish.info> wrote:
> J'aimerai savoir si les mises à jours des dépôts de sid
> sont effectués de façon régulière et est ce qu'il y a des
> moments particulier dans la journées où il est plus
> recommander d'effectuer des mises à jours de son système ?
Il y a plusieurs MÃ J/24H.
[â¦]
On Wed, 08 May 2013 18:05:08 +0200
Goldy wrote:
> J'aimerai savoir si les mises à jours des dépôts de sid
> sont effectués de façon régulière et est ce qu'il y a des
> moments particulier dans la journées où il est plus
> recommander d'effectuer des mises à jours de son système ?
Il y a plusieurs MÃ J/24H.
[â¦]
[â¦]
[â¦]
[â¦]
BonjourJe peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépendances non
satisfaites, ça risque d'être un peu galère.
Sans vouloir être rabat-joie, sid porte le nom de "unstable" pour une
bonne raison. C'est pourquoi il faut *toujours* faire attention.
Les paquets ne sont pas disponibles de façon régulière, bien que les
développeurs fassent de leur mieux pour pousser les nouvelles versions
avec leurs dépendances en peu de temps. Par contre, les serveurs sont
synchronisés de façon périodique. À minuit? Toutes les heures? Ça, il
faut vérifier...
Bonjour
Je peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépendances non
satisfaites, ça risque d'être un peu galère.
Sans vouloir être rabat-joie, sid porte le nom de "unstable" pour une
bonne raison. C'est pourquoi il faut *toujours* faire attention.
Les paquets ne sont pas disponibles de façon régulière, bien que les
développeurs fassent de leur mieux pour pousser les nouvelles versions
avec leurs dépendances en peu de temps. Par contre, les serveurs sont
synchronisés de façon périodique. À minuit? Toutes les heures? Ça, il
faut vérifier...
BonjourJe peux globalement faire attention, mais si je me retrouve toujours
avec des paquets qui ne sont pas installable à cause de dépendances non
satisfaites, ça risque d'être un peu galère.
Sans vouloir être rabat-joie, sid porte le nom de "unstable" pour une
bonne raison. C'est pourquoi il faut *toujours* faire attention.
Les paquets ne sont pas disponibles de façon régulière, bien que les
développeurs fassent de leur mieux pour pousser les nouvelles versions
avec leurs dépendances en peu de temps. Par contre, les serveurs sont
synchronisés de façon périodique. À minuit? Toutes les heures? Ça, il
faut vérifier...
C'est bien pour ça que je pose la question. L'idée étant j ustement de
savoir lorsque les paquets passent de experimental à unstable, s'ils
le font de manière relativement cohérentes ou non et si c'est l e cas,
si cela est fait selon un planing prédéfinit ou de manière anarchique.
à ce propos, je me demande si cela serait pertinent de réaliser un
dépôt alternatif à sid basés exclusivement sur des sc ripts qui
importerait les paquets en fonction de leur ancienneté et de la
satisfaction de leur dépendances. Je me demande d'ailleurs si un tel
script n'aurait pas déjà été développé.
C'est bien pour ça que je pose la question. L'idée étant j ustement de
savoir lorsque les paquets passent de experimental à unstable, s'ils
le font de manière relativement cohérentes ou non et si c'est l e cas,
si cela est fait selon un planing prédéfinit ou de manière anarchique.
à ce propos, je me demande si cela serait pertinent de réaliser un
dépôt alternatif à sid basés exclusivement sur des sc ripts qui
importerait les paquets en fonction de leur ancienneté et de la
satisfaction de leur dépendances. Je me demande d'ailleurs si un tel
script n'aurait pas déjà été développé.
C'est bien pour ça que je pose la question. L'idée étant j ustement de
savoir lorsque les paquets passent de experimental à unstable, s'ils
le font de manière relativement cohérentes ou non et si c'est l e cas,
si cela est fait selon un planing prédéfinit ou de manière anarchique.
à ce propos, je me demande si cela serait pertinent de réaliser un
dépôt alternatif à sid basés exclusivement sur des sc ripts qui
importerait les paquets en fonction de leur ancienneté et de la
satisfaction de leur dépendances. Je me demande d'ailleurs si un tel
script n'aurait pas déjà été développé.
[â¦]
C'est bien pour ça que je pose la question. L'idée étant
justement de savoir lorsque les paquets passent de
experimental à unstable, s'ils le font de manière
relativement cohérentes ou non et si c'est le cas, si cela
est fait selon un planing prédéfinit ou de manière
anarchique.
à ce propos, je me demande si cela serait pertinent de
réaliser un dépôt alternatif à sid basés exclusi vement sur
des scripts qui importerait les paquets en fonction de leur
ancienneté et de la satisfaction de leur dépendances. Je me
demande d'ailleurs si un tel script n'aurait pas déjà ét é
développé.
[â¦]
C'est bien pour ça que je pose la question. L'idée étant
justement de savoir lorsque les paquets passent de
experimental à unstable, s'ils le font de manière
relativement cohérentes ou non et si c'est le cas, si cela
est fait selon un planing prédéfinit ou de manière
anarchique.
à ce propos, je me demande si cela serait pertinent de
réaliser un dépôt alternatif à sid basés exclusi vement sur
des scripts qui importerait les paquets en fonction de leur
ancienneté et de la satisfaction de leur dépendances. Je me
demande d'ailleurs si un tel script n'aurait pas déjà ét é
développé.
[â¦]
C'est bien pour ça que je pose la question. L'idée étant
justement de savoir lorsque les paquets passent de
experimental à unstable, s'ils le font de manière
relativement cohérentes ou non et si c'est le cas, si cela
est fait selon un planing prédéfinit ou de manière
anarchique.
à ce propos, je me demande si cela serait pertinent de
réaliser un dépôt alternatif à sid basés exclusi vement sur
des scripts qui importerait les paquets en fonction de leur
ancienneté et de la satisfaction de leur dépendances. Je me
demande d'ailleurs si un tel script n'aurait pas déjà ét é
développé.
Faut-il attendre encore quelques semaines pour
uograder Debian de Squeeze vers Wheezy ?
Faut-il attendre encore quelques semaines pour
uograder Debian de Squeeze vers Wheezy ?
Faut-il attendre encore quelques semaines pour
uograder Debian de Squeeze vers Wheezy ?
Le mercredi 8 mai 2013 à 19:14:19, Goldy a écrit :[…]
C'est bien pour ça que je pose la question. L'idée étant
justement de savoir lorsque les paquets passent de
experimental à unstable, s'ils le font de manière
relativement cohérentes ou non et si c'est le cas, si cela
est fait selon un planing prédéfinit ou de manière
anarchique.
Les paquets ne passent pas de experimental à unstable.
Contrairement à oldstable, stable, testing et unstable qui
sont des distributions (= dépôt autosuffisant), experimental
est juste un dépôt incomplet (comme backport) pour des paquets
en test. Avant son existence, chaque DD qui voulait qu’on l’aide
à tester ses paquets devait le mettre à disposition et
l’annoncer comme il pouvait. Experimental sert juste à gérer ça
plus proprement, simplement, efficacement et de façon plus
ouverte (à d’autres testeurs).
Les paquets qui arrivent dans unstable (pour descendre après
dans testing), passent par la file NEW, accessible uniquement
aux DD (ayant droit d’upload) et gérée par les ftp-masters.
Donc, quand un paquet finit par plaire suffisamment à son DD,
celui-ci l’envoie vers « incoming » et les responsables le
mettent dans NEW (ou pas) et la charrette le ramasse au tour
suivant (genre tâche cron) pour le mettre dans les dépôts.
À ce propos, je me demande si cela serait pertinent de
réaliser un dépôt alternatif à sid basés exclusivement sur
des scripts qui importerait les paquets en fonction de leur
ancienneté et de la satisfaction de leur dépendances. Je me
demande d'ailleurs si un tel script n'aurait pas déjà été
développé.
Donc, en gros, une Testing sans le filtre « on attentd parce
qu’il y a des bogues » ?
Le mercredi 8 mai 2013 à 19:14:19, Goldy a écrit :
[…]
C'est bien pour ça que je pose la question. L'idée étant
justement de savoir lorsque les paquets passent de
experimental à unstable, s'ils le font de manière
relativement cohérentes ou non et si c'est le cas, si cela
est fait selon un planing prédéfinit ou de manière
anarchique.
Les paquets ne passent pas de experimental à unstable.
Contrairement à oldstable, stable, testing et unstable qui
sont des distributions (= dépôt autosuffisant), experimental
est juste un dépôt incomplet (comme backport) pour des paquets
en test. Avant son existence, chaque DD qui voulait qu’on l’aide
à tester ses paquets devait le mettre à disposition et
l’annoncer comme il pouvait. Experimental sert juste à gérer ça
plus proprement, simplement, efficacement et de façon plus
ouverte (à d’autres testeurs).
Les paquets qui arrivent dans unstable (pour descendre après
dans testing), passent par la file NEW, accessible uniquement
aux DD (ayant droit d’upload) et gérée par les ftp-masters.
Donc, quand un paquet finit par plaire suffisamment à son DD,
celui-ci l’envoie vers « incoming » et les responsables le
mettent dans NEW (ou pas) et la charrette le ramasse au tour
suivant (genre tâche cron) pour le mettre dans les dépôts.
À ce propos, je me demande si cela serait pertinent de
réaliser un dépôt alternatif à sid basés exclusivement sur
des scripts qui importerait les paquets en fonction de leur
ancienneté et de la satisfaction de leur dépendances. Je me
demande d'ailleurs si un tel script n'aurait pas déjà été
développé.
Donc, en gros, une Testing sans le filtre « on attentd parce
qu’il y a des bogues » ?
Le mercredi 8 mai 2013 à 19:14:19, Goldy a écrit :[…]
C'est bien pour ça que je pose la question. L'idée étant
justement de savoir lorsque les paquets passent de
experimental à unstable, s'ils le font de manière
relativement cohérentes ou non et si c'est le cas, si cela
est fait selon un planing prédéfinit ou de manière
anarchique.
Les paquets ne passent pas de experimental à unstable.
Contrairement à oldstable, stable, testing et unstable qui
sont des distributions (= dépôt autosuffisant), experimental
est juste un dépôt incomplet (comme backport) pour des paquets
en test. Avant son existence, chaque DD qui voulait qu’on l’aide
à tester ses paquets devait le mettre à disposition et
l’annoncer comme il pouvait. Experimental sert juste à gérer ça
plus proprement, simplement, efficacement et de façon plus
ouverte (à d’autres testeurs).
Les paquets qui arrivent dans unstable (pour descendre après
dans testing), passent par la file NEW, accessible uniquement
aux DD (ayant droit d’upload) et gérée par les ftp-masters.
Donc, quand un paquet finit par plaire suffisamment à son DD,
celui-ci l’envoie vers « incoming » et les responsables le
mettent dans NEW (ou pas) et la charrette le ramasse au tour
suivant (genre tâche cron) pour le mettre dans les dépôts.
À ce propos, je me demande si cela serait pertinent de
réaliser un dépôt alternatif à sid basés exclusivement sur
des scripts qui importerait les paquets en fonction de leur
ancienneté et de la satisfaction de leur dépendances. Je me
demande d'ailleurs si un tel script n'aurait pas déjà été
développé.
Donc, en gros, une Testing sans le filtre « on attentd parce
qu’il y a des bogues » ?