Par contre, l'OS n'est pas libre. Il faut bien faire des choix... Je ne vois pas le rapport. Ce que tu décris est largement possible sous un
OS libre. Bien sûr, mais entre la théorie et la pratique...
On peut très bien en pratique telecharger des versions binaires de firefox et les installer en meme temps.
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa distribution en n'utilisant pas le gestionnaire de paquets. Ce n'est donc pas une possibilité prévue par la distribution.
Et sous ton OS proprio firefox t'es proposé dans un gestionnaire de paquets ?
Idéalement, via le gestionnaire de paquets, on devrait pouvoir choisir la version voulue, et le cas échéant pouvoir faire marche arrière quand la dernière version a un bug dérangeant, mais malheureusement aucune distribution ne propose celà (du moins, à ma connaissance).
Sur Mandriva il y a une version supportée avec mises à jour de sécurité quand il y a besoin, et pour certains logiciels il y a un media "backports" qui propose des versions plus récentes.
On 2007-12-31, Jerome Lambert <jerome.lambert@swing.be> wrote:
On 2007-12-31, Jerome Lambert <jerome.lambert@swing.be> wrote:
Jerome Lambert , dans le message
Par contre, l'OS n'est pas libre. Il
faut bien faire des choix...
Je ne vois pas le rapport. Ce que tu décris est largement possible sous un
OS libre.
Bien sûr, mais entre la théorie et la pratique...
On peut très bien en pratique telecharger des versions binaires de
firefox et les installer en meme temps.
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa
distribution en n'utilisant pas le gestionnaire de paquets. Ce n'est
donc pas une possibilité prévue par la distribution.
Et sous ton OS proprio firefox t'es proposé dans un gestionnaire de
paquets ?
Idéalement, via le gestionnaire de paquets, on devrait pouvoir choisir
la version voulue, et le cas échéant pouvoir faire marche arrière quand
la dernière version a un bug dérangeant, mais malheureusement aucune
distribution ne propose celà (du moins, à ma connaissance).
Sur Mandriva il y a une version supportée avec mises à jour de sécurité
quand il y a besoin, et pour certains logiciels il y a un media
"backports" qui propose des versions plus récentes.
Par contre, l'OS n'est pas libre. Il faut bien faire des choix... Je ne vois pas le rapport. Ce que tu décris est largement possible sous un
OS libre. Bien sûr, mais entre la théorie et la pratique...
On peut très bien en pratique telecharger des versions binaires de firefox et les installer en meme temps.
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa distribution en n'utilisant pas le gestionnaire de paquets. Ce n'est donc pas une possibilité prévue par la distribution.
Et sous ton OS proprio firefox t'es proposé dans un gestionnaire de paquets ?
Idéalement, via le gestionnaire de paquets, on devrait pouvoir choisir la version voulue, et le cas échéant pouvoir faire marche arrière quand la dernière version a un bug dérangeant, mais malheureusement aucune distribution ne propose celà (du moins, à ma connaissance).
Sur Mandriva il y a une version supportée avec mises à jour de sécurité quand il y a besoin, et pour certains logiciels il y a un media "backports" qui propose des versions plus récentes.
Nicolas George
Jerome Lambert , dans le message <47792016$0$22311$, a écrit :
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa distribution en n'utilisant pas le gestionnaire de paquets.
Le système de paquets est quelque chose que les distributions d'OS libres ont _en plus_ des systèmes propriétaires. Installer quelque chose sans son aide revient à faire la même chose qu'ailleurs, et ça fonctionne aussi bien qu'ailleurs.
Jerome Lambert , dans le message
<47792016$0$22311$ba620e4c@news.skynet.be>, a écrit :
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa
distribution en n'utilisant pas le gestionnaire de paquets.
Le système de paquets est quelque chose que les distributions d'OS libres
ont _en plus_ des systèmes propriétaires. Installer quelque chose sans son
aide revient à faire la même chose qu'ailleurs, et ça fonctionne aussi bien
qu'ailleurs.
Jerome Lambert , dans le message <47792016$0$22311$, a écrit :
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa distribution en n'utilisant pas le gestionnaire de paquets.
Le système de paquets est quelque chose que les distributions d'OS libres ont _en plus_ des systèmes propriétaires. Installer quelque chose sans son aide revient à faire la même chose qu'ailleurs, et ça fonctionne aussi bien qu'ailleurs.
Benjamin FRANCOIS
ciol s'est exprimé en ces termes:
Comprenez : je veux seulement que les applications FINALES soient mises à jour systématiquement. Pas les BIBLIOTHÈQUES, ni le NOYAU, ni XORG.
Attendez: luc2 a changé de pseudo, c'est ça ?
-- When Batman is in trouble, he turns on the Jack Bauer signal.
ciol s'est exprimé en ces termes:
Comprenez : je veux seulement que les applications FINALES soient mises
à jour systématiquement.
Pas les BIBLIOTHÈQUES, ni le NOYAU, ni XORG.
Attendez: luc2 a changé de pseudo, c'est ça ?
--
When Batman is in trouble, he turns on the Jack Bauer signal.
Indeed. Je file picoler chez des amis, amuse-toi bien à réinstaller une distrib, ma couille.
C'est ça, courez profiter de la vie. C'est trop banal pour moi.
Raphaël 'SurcouF' Bordet
Je ne vois pas comment on peut dissocier applications et bibliothèque s, si une appli dépend d'une nouvelle version de lib il faut bien la mettre à jour aussi (au risque de casser d'autre appli).
Bah non. On arrête de mettre à jour l'application, c'est tout. Ça s era toujours mieux que le système actuel, où on arrête de mettre à jo ur aléatoirement (i.e quand on sort une nouvelle release de la distributio n).
Par exemple, X dans sa branche 1 dépend de gtk 2.8. X sort une nouvelle branche, la 2, qui dépend de gtk 2.10 (qui n'est pa s dans notre distrib). Ben on met pas à jour X dans sa branche 2. C'est aussi simple que ça.
La notion de versions concurrentes au sein d'une même distribution t'es manifestement totalement étrangère. Pourtant, c'est ainsi qu'on peut avoir à la fois GTK+ 1.2.x et GTK+ 2.x.y sous Debian et Ubuntu (pour ne citer que ces distributions-là). Évidemment, il appartient aux responsables de paquets de maintenir des paquets binaires pour chaque révision de GTK+ mais si tu veux le faire, pourquoi pas. Je ne pense pas que ça ait un quelconque intérêt.
Vous verrez que pour les applications grands publics, si on a un cycle de release correcte, ça arrivera pas souvent (ex. firefox dépend de g tk 2.4)
À minima, oui. Mais tu noteras que rien ne nous empêche d'avoir GTK+ 2.12.x sans que ça ne dérange Firefox le moins du monde. En fait, ce qu i dérange le plus dans les mises à jour des différentes versions (je di s bien versions et non révisions), la 1.5, la 2 puis la 3, ce sont les nombreuses extensions dont les utilisateurs sont friands. Je l'ai vécu quand les utilisateurs d'Ubuntu sont passés successivement à Firefox 1. 5 puis à Firefox 2.0. La plupart ne passaient à la nouvelle version parce que leur extension favorite n'était pas encore compatible. Donc, il vaut parfois mieux qu'il y a un délai entre la sortie officielle d'un logiciel par les responsables du projet et sa disponibilité dans la distribution de ton choix. Ainsi, cela peut permettre à des logiciels tiers (comme les extensions de Firefox) d'êtr e enfin compatibles. Sans même parler de stabiliser le dit logiciel (tous les logiciels publiés en version stable ne bénéficient pas tous de la même assurance qualité.
-- Raphaël SurcouF
Je ne vois pas comment on peut dissocier applications et bibliothèque s, si
une appli dépend d'une nouvelle version de lib il faut bien la mettre à
jour aussi (au risque de casser d'autre appli).
Bah non. On arrête de mettre à jour l'application, c'est tout. Ça s era
toujours mieux que le système actuel, où on arrête de mettre à jo ur
aléatoirement (i.e quand on sort une nouvelle release de la distributio n).
Par exemple, X dans sa branche 1 dépend de gtk 2.8.
X sort une nouvelle branche, la 2, qui dépend de gtk 2.10 (qui n'est pa s
dans notre distrib).
Ben on met pas à jour X dans sa branche 2. C'est aussi simple que ça.
La notion de versions concurrentes au sein d'une même distribution t'es
manifestement totalement étrangère.
Pourtant, c'est ainsi qu'on peut avoir à la fois GTK+ 1.2.x et GTK+
2.x.y sous Debian et Ubuntu (pour ne citer que ces distributions-là).
Évidemment, il appartient aux responsables de paquets de maintenir des
paquets binaires pour chaque révision de GTK+ mais si tu veux le faire,
pourquoi pas. Je ne pense pas que ça ait un quelconque intérêt.
Vous verrez que pour les applications grands publics, si on a un cycle
de release correcte, ça arrivera pas souvent (ex. firefox dépend de g tk 2.4)
À minima, oui. Mais tu noteras que rien ne nous empêche d'avoir GTK+
2.12.x sans que ça ne dérange Firefox le moins du monde. En fait, ce qu i
dérange le plus dans les mises à jour des différentes versions (je di s
bien versions et non révisions), la 1.5, la 2 puis la 3, ce sont les
nombreuses extensions dont les utilisateurs sont friands. Je l'ai vécu
quand les utilisateurs d'Ubuntu sont passés successivement à Firefox 1. 5
puis à Firefox 2.0. La plupart ne passaient à la nouvelle version parce
que leur extension favorite n'était pas encore compatible.
Donc, il vaut parfois mieux qu'il y a un délai entre la sortie
officielle d'un logiciel par les responsables du projet et sa
disponibilité dans la distribution de ton choix. Ainsi, cela peut
permettre à des logiciels tiers (comme les extensions de Firefox) d'êtr e
enfin compatibles. Sans même parler de stabiliser le dit logiciel (tous
les logiciels publiés en version stable ne bénéficient pas tous de la
même assurance qualité.
Je ne vois pas comment on peut dissocier applications et bibliothèque s, si une appli dépend d'une nouvelle version de lib il faut bien la mettre à jour aussi (au risque de casser d'autre appli).
Bah non. On arrête de mettre à jour l'application, c'est tout. Ça s era toujours mieux que le système actuel, où on arrête de mettre à jo ur aléatoirement (i.e quand on sort une nouvelle release de la distributio n).
Par exemple, X dans sa branche 1 dépend de gtk 2.8. X sort une nouvelle branche, la 2, qui dépend de gtk 2.10 (qui n'est pa s dans notre distrib). Ben on met pas à jour X dans sa branche 2. C'est aussi simple que ça.
La notion de versions concurrentes au sein d'une même distribution t'es manifestement totalement étrangère. Pourtant, c'est ainsi qu'on peut avoir à la fois GTK+ 1.2.x et GTK+ 2.x.y sous Debian et Ubuntu (pour ne citer que ces distributions-là). Évidemment, il appartient aux responsables de paquets de maintenir des paquets binaires pour chaque révision de GTK+ mais si tu veux le faire, pourquoi pas. Je ne pense pas que ça ait un quelconque intérêt.
Vous verrez que pour les applications grands publics, si on a un cycle de release correcte, ça arrivera pas souvent (ex. firefox dépend de g tk 2.4)
À minima, oui. Mais tu noteras que rien ne nous empêche d'avoir GTK+ 2.12.x sans que ça ne dérange Firefox le moins du monde. En fait, ce qu i dérange le plus dans les mises à jour des différentes versions (je di s bien versions et non révisions), la 1.5, la 2 puis la 3, ce sont les nombreuses extensions dont les utilisateurs sont friands. Je l'ai vécu quand les utilisateurs d'Ubuntu sont passés successivement à Firefox 1. 5 puis à Firefox 2.0. La plupart ne passaient à la nouvelle version parce que leur extension favorite n'était pas encore compatible. Donc, il vaut parfois mieux qu'il y a un délai entre la sortie officielle d'un logiciel par les responsables du projet et sa disponibilité dans la distribution de ton choix. Ainsi, cela peut permettre à des logiciels tiers (comme les extensions de Firefox) d'êtr e enfin compatibles. Sans même parler de stabiliser le dit logiciel (tous les logiciels publiés en version stable ne bénéficient pas tous de la même assurance qualité.
-- Raphaël SurcouF
Raphaël 'SurcouF' Bordet
Le projet wine est mis à jour _très_ souvent.
Bon début. Une version stable, c'est testée. Si un logiciel est tro p souvent mis à jour, il n'y a pas le temps de tester toutes ses mises à jour et de les intégrer à chaque fois.
Je vais faire une affirmation que tous les mainteneurs debian devrait se mettre dans la tête : « L'utilisateur final*, il en a rien à faire qu'une application *fina le* plante à cause d'une mise à jour. »
Si, si, il en a quelque chose à faire. Ça ne fait pas plaisir à un développeur Debian d'avoir des rapports d'anomalies parce qu'une mise à jour a rendu la vie impossible aux utilisateurs. Et encore, je te parle des utilisateurs de la version « unstable » de Debian. Pour la version « stable », c'est encore pire.
- Parce que, comme seule cette application aura été mise à jour (et pas les bibliothèques et tout le bordel important), il saura d'où vient l e problème, que ce problème vient de l'upstream et pas de la distributi on.
C'est tellement évident que, il y a deux ans, je n'ai pas compris pourquoi mon imprimante ne fonctionnait plus suite à une mise à jour de cups sous Debian unstable. D'autant plus qu'un liveCD de l'Ubuntu de l'époque, à peine sortie, parvenait sans mal à la faire fonctionner. Depuis, j'ai fini par basculer à Ubuntu. Non pas que le problème n'ait pu être corrigé sous Debian mais « sid » ne correspond pas vraiment à l'utilisation d'un utilisateur final comme tu dis. Ubuntu est mise suffisamment à jour pour disposer assez rapidement des nouveautés (comm e compiz-fusion sous gutsy, après que tous les « béta-testeurs » aien t finis de se casser les dents avec compiz et autres beryl) et disposer toutefois d'un système assez stable pendant une bonne période.
- Parce qu'il pourra facilement revenir à la version précédente.
AHAHAHAHAHA. Tu parles toujours de l'utilisateur final, là ? Je veux bien que tu lui expliques comment il doit s'y prendre.
En sachant que Wine, c'est pour les gens qui ne peuvent pas se passer d e Windows, c'est _très_ loin d'être primordial.
Je vous vois venir : je n'utilise pas wine. Mais je me mets à la place de l'ubunteros.
Qu'est-ce qu'un « ubunteros » selon toi ? Un utilisateur d'Ubuntu ? Dans ce cas, il suffirait que tu l'utilises pour en être un, mais ça ne te donnerais certainement pas le droit ni la prétention de parler au nom des autres.
Et surtout, depuis quand les mainteneurs de distributions pensent à la place de leurs utilisateurs, pour leur imposer une version particulière ? Depuis quand un logiciel est primordial ou non ? En vertu de quoi on a plus le droit de vouloir mettre à jour son logiciel, même si ça ser t à rien, mais tout simplement parce qu'on veut nous aussi voir les avancée s de l'upstream ?
Pourquoi diable veux-tu mettre à jour un logiciel sans même savoir ce que les développeurs amonts ont pu apporter comme fonctionnalités ? Ce discours ne tient pas debout. Si tu suivais les développements apportés en dehors des versions stable des distributions, tu verrais que les développeurs des dites distributions apportent le soin nécessaire pour que les prochaines versions soient disponibles le plus tôt possible sans pour autant tout casser.
-- Raphaël SurcouF
Le projet wine est mis à jour _très_ souvent.
Bon début. Une version stable, c'est testée. Si un logiciel est tro p souvent
mis à jour, il n'y a pas le temps de tester toutes ses mises à jour et de
les intégrer à chaque fois.
Je vais faire une affirmation que tous les mainteneurs debian devrait se
mettre dans la tête :
« L'utilisateur final*, il en a rien à faire qu'une application *fina le*
plante à cause d'une mise à jour. »
Si, si, il en a quelque chose à faire. Ça ne fait pas plaisir à un
développeur Debian d'avoir des rapports d'anomalies parce qu'une mise à
jour a rendu la vie impossible aux utilisateurs. Et encore, je te parle
des utilisateurs de la version « unstable » de Debian. Pour la version «
stable », c'est encore pire.
- Parce que, comme seule cette application aura été mise à jour (et pas
les bibliothèques et tout le bordel important), il saura d'où vient l e
problème, que ce problème vient de l'upstream et pas de la distributi on.
C'est tellement évident que, il y a deux ans, je n'ai pas compris
pourquoi mon imprimante ne fonctionnait plus suite à une mise à jour de
cups sous Debian unstable. D'autant plus qu'un liveCD de l'Ubuntu de
l'époque, à peine sortie, parvenait sans mal à la faire fonctionner.
Depuis, j'ai fini par basculer à Ubuntu. Non pas que le problème n'ait
pu être corrigé sous Debian mais « sid » ne correspond pas vraiment à
l'utilisation d'un utilisateur final comme tu dis. Ubuntu est mise
suffisamment à jour pour disposer assez rapidement des nouveautés (comm e
compiz-fusion sous gutsy, après que tous les « béta-testeurs » aien t
finis de se casser les dents avec compiz et autres beryl) et disposer
toutefois d'un système assez stable pendant une bonne période.
- Parce qu'il pourra facilement revenir à la version précédente.
AHAHAHAHAHA.
Tu parles toujours de l'utilisateur final, là ? Je veux bien que tu lui
expliques comment il doit s'y prendre.
En sachant que Wine, c'est pour les gens qui ne peuvent pas se passer d e
Windows, c'est _très_ loin d'être primordial.
Je vous vois venir : je n'utilise pas wine.
Mais je me mets à la place de l'ubunteros.
Qu'est-ce qu'un « ubunteros » selon toi ? Un utilisateur d'Ubuntu ?
Dans ce cas, il suffirait que tu l'utilises pour en être un, mais ça ne
te donnerais certainement pas le droit ni la prétention de parler au nom
des autres.
Et surtout, depuis quand les mainteneurs de distributions pensent à la
place de leurs utilisateurs, pour leur imposer une version particulière
? Depuis quand un logiciel est primordial ou non ? En vertu de quoi on a
plus le droit de vouloir mettre à jour son logiciel, même si ça ser t à
rien, mais tout simplement parce qu'on veut nous aussi voir les avancée s
de l'upstream ?
Pourquoi diable veux-tu mettre à jour un logiciel sans même savoir ce
que les développeurs amonts ont pu apporter comme fonctionnalités ? Ce
discours ne tient pas debout.
Si tu suivais les développements apportés en dehors des versions stable
des distributions, tu verrais que les développeurs des dites
distributions apportent le soin nécessaire pour que les prochaines
versions soient disponibles le plus tôt possible sans pour autant tout
casser.
Bon début. Une version stable, c'est testée. Si un logiciel est tro p souvent mis à jour, il n'y a pas le temps de tester toutes ses mises à jour et de les intégrer à chaque fois.
Je vais faire une affirmation que tous les mainteneurs debian devrait se mettre dans la tête : « L'utilisateur final*, il en a rien à faire qu'une application *fina le* plante à cause d'une mise à jour. »
Si, si, il en a quelque chose à faire. Ça ne fait pas plaisir à un développeur Debian d'avoir des rapports d'anomalies parce qu'une mise à jour a rendu la vie impossible aux utilisateurs. Et encore, je te parle des utilisateurs de la version « unstable » de Debian. Pour la version « stable », c'est encore pire.
- Parce que, comme seule cette application aura été mise à jour (et pas les bibliothèques et tout le bordel important), il saura d'où vient l e problème, que ce problème vient de l'upstream et pas de la distributi on.
C'est tellement évident que, il y a deux ans, je n'ai pas compris pourquoi mon imprimante ne fonctionnait plus suite à une mise à jour de cups sous Debian unstable. D'autant plus qu'un liveCD de l'Ubuntu de l'époque, à peine sortie, parvenait sans mal à la faire fonctionner. Depuis, j'ai fini par basculer à Ubuntu. Non pas que le problème n'ait pu être corrigé sous Debian mais « sid » ne correspond pas vraiment à l'utilisation d'un utilisateur final comme tu dis. Ubuntu est mise suffisamment à jour pour disposer assez rapidement des nouveautés (comm e compiz-fusion sous gutsy, après que tous les « béta-testeurs » aien t finis de se casser les dents avec compiz et autres beryl) et disposer toutefois d'un système assez stable pendant une bonne période.
- Parce qu'il pourra facilement revenir à la version précédente.
AHAHAHAHAHA. Tu parles toujours de l'utilisateur final, là ? Je veux bien que tu lui expliques comment il doit s'y prendre.
En sachant que Wine, c'est pour les gens qui ne peuvent pas se passer d e Windows, c'est _très_ loin d'être primordial.
Je vous vois venir : je n'utilise pas wine. Mais je me mets à la place de l'ubunteros.
Qu'est-ce qu'un « ubunteros » selon toi ? Un utilisateur d'Ubuntu ? Dans ce cas, il suffirait que tu l'utilises pour en être un, mais ça ne te donnerais certainement pas le droit ni la prétention de parler au nom des autres.
Et surtout, depuis quand les mainteneurs de distributions pensent à la place de leurs utilisateurs, pour leur imposer une version particulière ? Depuis quand un logiciel est primordial ou non ? En vertu de quoi on a plus le droit de vouloir mettre à jour son logiciel, même si ça ser t à rien, mais tout simplement parce qu'on veut nous aussi voir les avancée s de l'upstream ?
Pourquoi diable veux-tu mettre à jour un logiciel sans même savoir ce que les développeurs amonts ont pu apporter comme fonctionnalités ? Ce discours ne tient pas debout. Si tu suivais les développements apportés en dehors des versions stable des distributions, tu verrais que les développeurs des dites distributions apportent le soin nécessaire pour que les prochaines versions soient disponibles le plus tôt possible sans pour autant tout casser.
-- Raphaël SurcouF
Raphaël 'SurcouF' Bordet
On 2007-12-31, Jerome Lambert wrote:
Jerome Lambert , dans le message
Par contre, l'OS n'est pas libre. Il faut bien faire des choix... Je ne vois pas le rapport. Ce que tu décris est largement possible sous un
OS libre. Bien sûr, mais entre la théorie et la pratique...
On peut très bien en pratique telecharger des versions binaires de firefox et les installer en meme temps.
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa distribution en n'utilisant pas le gestionnaire de paquets. Ce n'est donc pas une possibilité prévue par la distribution.
Il faudra mettre à jour tes connaissances. Sous Ubuntu Gutsy, nous avons au menu : - firefox[1] ; - firefox-3.0[2].
Évidemment, il s'agit presque d'une exception à la règle mais il s'ag it là de l'exemple que tu as choisi. C'est dommage. Les distributions sont à même de pouvoir fournir plusieurs versions concurrentes d'un même logiciel. Il faut cependant bien distinguer les versions des révisions et numéros de patchs. Très souvent, une nouvelle révision n'apporte aucune fonctionnalité mais ne fait que corriger des bogues plus ou moins importants. Simplement, il n'est pas toujours possible de rétro-porter la correction vers la version actuellement utilisée. Cependant, si Debian ne réserve ses mises à jour que pour les bogues de très grande s sévérités ou touchant la sécurité, Ubuntu les effectue égalemen t pour des bogues de moindres importances mais tout ceci demande des développeurs pour faire ce travail ô combien ingrat.
Idéalement, via le gestionnaire de paquets, on devrait pouvoir choisir la version voulue, et le cas échéant pouvoir faire marche arrière q uand la dernière version a un bug dérangeant, mais malheureusement aucune distribution ne propose celà (du moins, à ma connaissance).
Paradoxalement, Debian propose un service[3] qui permet d'avoir les versions précédentes à la carte, mais c'est loin d'être utilisable pour tout le monde.
On 2007-12-31, Jerome Lambert <jerome.lambert@swing.be> wrote:
Jerome Lambert , dans le message
Par contre, l'OS n'est pas libre. Il
faut bien faire des choix...
Je ne vois pas le rapport. Ce que tu décris est largement possible sous un
OS libre.
Bien sûr, mais entre la théorie et la pratique...
On peut très bien en pratique telecharger des versions binaires de
firefox et les installer en meme temps.
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa
distribution en n'utilisant pas le gestionnaire de paquets. Ce n'est
donc pas une possibilité prévue par la distribution.
Il faudra mettre à jour tes connaissances.
Sous Ubuntu Gutsy, nous avons au menu :
- firefox[1] ;
- firefox-3.0[2].
Évidemment, il s'agit presque d'une exception à la règle mais il s'ag it
là de l'exemple que tu as choisi. C'est dommage. Les distributions sont
à même de pouvoir fournir plusieurs versions concurrentes d'un même
logiciel. Il faut cependant bien distinguer les versions des révisions
et numéros de patchs. Très souvent, une nouvelle révision n'apporte
aucune fonctionnalité mais ne fait que corriger des bogues plus ou moins
importants. Simplement, il n'est pas toujours possible de rétro-porter
la correction vers la version actuellement utilisée. Cependant, si
Debian ne réserve ses mises à jour que pour les bogues de très grande s
sévérités ou touchant la sécurité, Ubuntu les effectue égalemen t pour
des bogues de moindres importances mais tout ceci demande des
développeurs pour faire ce travail ô combien ingrat.
Idéalement, via le gestionnaire de paquets, on devrait pouvoir choisir
la version voulue, et le cas échéant pouvoir faire marche arrière q uand
la dernière version a un bug dérangeant, mais malheureusement aucune
distribution ne propose celà (du moins, à ma connaissance).
Paradoxalement, Debian propose un service[3] qui permet d'avoir les
versions précédentes à la carte, mais c'est loin d'être utilisable pour
tout le monde.
Par contre, l'OS n'est pas libre. Il faut bien faire des choix... Je ne vois pas le rapport. Ce que tu décris est largement possible sous un
OS libre. Bien sûr, mais entre la théorie et la pratique...
On peut très bien en pratique telecharger des versions binaires de firefox et les installer en meme temps.
Sauf que dans ce cas on sort du cadre d'utilisation normale de sa distribution en n'utilisant pas le gestionnaire de paquets. Ce n'est donc pas une possibilité prévue par la distribution.
Il faudra mettre à jour tes connaissances. Sous Ubuntu Gutsy, nous avons au menu : - firefox[1] ; - firefox-3.0[2].
Évidemment, il s'agit presque d'une exception à la règle mais il s'ag it là de l'exemple que tu as choisi. C'est dommage. Les distributions sont à même de pouvoir fournir plusieurs versions concurrentes d'un même logiciel. Il faut cependant bien distinguer les versions des révisions et numéros de patchs. Très souvent, une nouvelle révision n'apporte aucune fonctionnalité mais ne fait que corriger des bogues plus ou moins importants. Simplement, il n'est pas toujours possible de rétro-porter la correction vers la version actuellement utilisée. Cependant, si Debian ne réserve ses mises à jour que pour les bogues de très grande s sévérités ou touchant la sécurité, Ubuntu les effectue égalemen t pour des bogues de moindres importances mais tout ceci demande des développeurs pour faire ce travail ô combien ingrat.
Idéalement, via le gestionnaire de paquets, on devrait pouvoir choisir la version voulue, et le cas échéant pouvoir faire marche arrière q uand la dernière version a un bug dérangeant, mais malheureusement aucune distribution ne propose celà (du moins, à ma connaissance).
Paradoxalement, Debian propose un service[3] qui permet d'avoir les versions précédentes à la carte, mais c'est loin d'être utilisable pour tout le monde.
