Suite à de nombreuses incompréhensions entre les programmeurs d'Owncloud et le mainteneur du paquet Debian, ce dernier a choisi de supprimer tous les paquets Owncloud des dépôts Debian (Source)
À noter, il semble que d'autres distributions avaient déjà fait le même choix pour des raisons similaires.
Et vous, utilisez-vous encore Owncloud ? Pensez-vous que c'est l'occasion rêvée pour Nextcloud de s'imposer ?
# ça date un peu...
Posté par ZeroHeure . Évalué à 2.
Ben mon vieux, elle n'est pas neuve celle-la ! Tu sais que ça date de mars 2016 ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: ça date un peu...
Posté par Cyril Brulebois (site web personnel) . Évalué à 10. Dernière modification le 19 décembre 2016 à 03:02.
Il n'y a aucun paquet
nextclouddans Debian à l'heure actuelle (y compris dansunstable/experimental), et je ne vois personne en train de préparer le taf : « RFP: nextcloud—self-hosted cloud services » (cf. https://bugs.debian.org/835086).Note/rappel : RFP est pour Request For Package, qui sera(it) basculé en ITP (Intent To Package) pour signaler un début d'effort d'intégration dudit logiciel dans la distribution.
La deadline pour avoir un paquet dans la prochaine version stable étant au 5 janvier, ça ressemble à une occasion manquée (et/ou une volonté sous-jacente de ne pas être packagé dans telle ou telle distribution, je n'ai pas suivi les derniers développements des flamewars nuagesques).
(Note : J'ai cliqué Répondre naïvement plutôt qu'Envoyer un commentaire, cette réponse est donc threadée sous celle de ZeroHeure, mais sans rapport direct. Sorry.)
Debian Consultant @ DEBAMAX
[^] # Re: ça date un peu...
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Quand on suit un peu les liens, je comprends les problématiques techniques des 2 côtés: Debian veut pouvoir fournir un logiciel stable (sans faire de mise-à-jour majeure forcée si on veut juste profiter des corrections de bug) alors qu'Owncloud veut pousser les gens à mettre à jour le plus possible (et j'imagine qu'en tant que petite boîte, ils n'ont pas forcément les moyens humains pour maintenir trop longtemps de vieilles versions). Le problème était donc que les packagers Debian patchaient Owncloud pour créer leur propre système de mise à jour leur permettant de sauter des versions majeures (le but étant — j'imagine — de pouvoir mettre à jour Owncloud tous les X années, à chaque sortie de Debian, durée pendant laquelle il y aurait eu plusieurs versions majeures d'Owncloud, en ne proposant que les corrections de bugs dans l'intermède).
Perso, je comprends les deux raisons. Le problème semble réellement essentiellement humain, notamment le développeur Owncloud qui dit sur les mailing lists que le mainteneur Debian est un irresponsable. C'est sûr que ce n'est pas forcément très diplomatique. :-/
Quand on lit ton lien, on se rend compte que les packagers Debian sont surtout vraiment pas chauds et considèrent la relation avec Nextcloud tout aussi problématique que celle avec Owncloud. En fait pire, le dév hostile fait justement partie des gens qui sont partis d'Owncloud vers Nextcloud! Donc en un sens, même si c'était sous le nom "Owncloud" (car à l'époque Nextcloud n'existait pas encore), on pourrait dire que c'est tout autant voire plus la relation avec Nextcloud qui fut rompue.
Ceci dit, le dernier message (à ce jour) de ce rapport de bug dit aussi que Nextcloud a annoncé la possibilité de mettre à jour en sautant des versions, ce qui est exactement ce qui posait problème à Debian et qu'ils espèrent que Debian aura un paquet. Ce n'est donc pas entièrement fermé, semblerait-il. Il faut juste voir comment se passera le côté relationnel car ça semble avoir vraiment été très mal vécu du côté Debian.
En tous cas, c'est toujours triste de lire ce type de mésententes. ;-(
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ça date un peu...
Posté par windu.2b . Évalué à 8.
Linus est aussi sur les ML d'OwnCloud ? :-O
(je sais qu'on n'est que lundi, mais la semaine avant Noël, c'est un comme "le vendredi de l'année", non ?)
[^] # Re: ça date un peu...
Posté par Firwen (site web personnel) . Évalué à 10.
J'appellerai pas ça un problème de mésententes, c'est surtout un problème classique de point de vue développeur vs packageur.
Le développeur veut pusher vers la dernière version de son software, et généralement sous-évalue l'importance de la rétro-compatibilité et le coté disruptifs de ses mise à jour
Le packageur ( ou l'admin ) se DOIT de fournir une rétro-compatibilité et des updates sans casse. Sous peine de voir la moitié de son département passer par son bureau avec des fourches à chaque update.
Pour être fait correctement, l'aspect déploiement et mise à jour d'un software doit être prise en compte dés le début de sa conception ( ABI, API publique, API privé, protocols, schéma DB,… ).
Si ce n'est pas le cas, ça vire très rapidement au désastre. Et dans le cas de owncloud ( et de beaucoup de softs en PHP au passage), ça n'a pas été le cas.
[^] # Re: ça date un peu...
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 19 décembre 2016 à 15:19.
Bien sûr. Mais justement cela aurait pu être fait dans la joie et la bonne humeur. ;-)
Par exemple, puisque le packager Debian patchait Owncloud pour justement permettre de sauter des versions lors des mises à jour, peut-être ces patchs auraient-ils pu être repris upstream (et éventuellement corrigés/améliorés/nettoyés selon les standards du projet)? Le fait est que maintenant Nextcloud (et probablement Owncloud) souhaite avoir cette fonctionnalité de toutes façons, les forces auraient pu être jointes plutôt que les ponts rompus.
C'est là où il y a eu mésentente. Avec de simples discussions aimables, bien sûr cela ne résoud pas forcément le problème technique. Peut-être le travail en cours de Debian n'était pas acceptable d'un point qualitatif par Owncloud, mais c'est aussi exprimable de manière constructive sans braquer l'autre côté. Et peut-être que cela aurait abouti à de nouvelles propositions de patchs qui se seraient rapprochées d'un truc livrable. Ou pas. Mais dans tous les cas, ce serait une meilleure situation que maintenant.
C'est le principe d'une revue de code. Quand je lis un patch, j'essaie de passer mes commentaires pour demander au contributeur d'améliorer son patch de manière agréable. Ça marche pas toujours. Certains faisaient juste un lâchage de patch et reviennent de toutes façons jamais. Certains peuvent le prendre mal malgré tous les efforts diplomatiques que l'on puisse faire pour dire que ça n'est pas suffisamment dans nos standards de qualité. Mais bon, faut essayer quand même.
Et dans le cas d'un packager Debian, qui maintient plein de patchs et depuis longtemps, je pense qu'il aurait pu prendre mieux une proposition d'inclure son travail moyennant des changements. Mais pour cela, il aurait fallu discuter (en lisant les commentaires des 2 côtés, j'ai l'impression qu'Owncloud se focalise sur un commit et ne s'est pas rendu compte que c'était une partie d'un travail en cours pour une mise à jour en sautant des versions).
Ensuite je ne connais pas le détail et surtout le passif de discussion. Je ne saurais dire qui est le plus en faute dans l’interaction sociale (et franchement ça m'intéresse pas de savoir). Je constate juste le résultat et trouve cela un peu triste.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ça date un peu...
Posté par reynum (site web personnel) . Évalué à 2.
Neuve ou pas moi je suis vert, car j'ai un serveur Debian avec Owncloud (que j'aime bien) et du coup fini les MAJ (remarque il n'y en avait plus beaucoup depuis longtemps).
Sans dec à quand une offre de cloud qui propose WebDav, CalDav, CardDav, un webmail sympa et un libreoffice distant et qui s'entende bien avec Debian ? ça doit pouvoir ce faire tout de même :-)
kentoc'h mervel eget bezan saotred
[^] # Re: ça date un peu...
Posté par Maclag . Évalué à 2.
Soit tu utilises leur propre dépôt, soit tu bascules vers les scripts partout.
Mais si tu voulais garder une version stable plus longtemps, tu te démerdes pour les mises à jour: les dévs ne veulent pas gérer les mises à jour qui sautent plusieurs versions ni assurer le support des vieilles versions, faute de moyens.
C'est agaçant pour les "admins" à temps occasionnel, mais ça se comprend aussi.
# Deux options
Posté par Maclag . Évalué à 4.
Debian a un dépôt "stable-updates", pour certains paquets tels que les antivirus. Peut-être qu'ils peuvent élargir leur champ d'acceptation.
Sinon, il y a l'option de faire un dépôt externe dédié.
[^] # Re: Deux options
Posté par Oli . Évalué à 2.
Le projet ownCloud met à disposition un dépôt pour plusieurs distributions :
- https://download.owncloud.org/download/repositories/stable/owncloud/
D'après ce que j'ai constaté ces derniers mois les packages sont très rapidement actualisés après la sortie des nouvelles versions d'ownCloud, au moins pour Debian et Centos.
Pour l'instant Nextcloud ne le fait pas à ma connaissance ma cela viendra peut-être.
# PPA pour Debian?
Posté par Benjamin Henrion (site web personnel) . Évalué à -4.
Un jour il va falloir que quelqu'un fasse un hosting PPA pour Debian.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: PPA pour Debian?
Posté par arnaudus . Évalué à 9.
Là je suis un peu paumé. N'est-ce pas l'intérêt majeur d'un système de paquets que de faire reposer la veille technologique et l'intégration des patches au mainteneur du paquet?
[^] # Re: PPA pour Debian?
Posté par EauFroide . Évalué à 2.
owncloud et nextcloud sont tous deux équipé du même module de mise a jours qui fonctionne franchement bien (tu cliques sur mettre a jours et il fait tout le job (sauf ré-activer les modules))
L'avantage est que tu peux update ton système quand tu veux et n'update ton [own|next]cloud que pendant la nuit (se qui évite les problèmes de coupure du service pendant que des montages webdav sont en cours d'utilisation).
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: PPA pour Debian?
Posté par Bernez . Évalué à 10.
Ça a le même intérêt que pour toute application : installation facile et standardisée, mises à jour de sécurité gérées par la distribution. L'intérêt est même supérieur à la moyenne vu que les applications web sont particulièrement affectées par les problèmes de sécurité.
Ces applications s'installent là ou le mainteneur l'a décidé, ce qui est correspond donc précisément au choix de l'administrateur système (puisque l'administrateur a choisi sa distribution, et que tout le principe d'une distribution est d'avoir une politique cohérente d'administration système).
Cette mode d'avoir un système de mise à jour par logiciel finit par devenir pénible. Toutes les entreprises (sans parler des particuliers) ne peuvent pas se permettre de payer des armées d'informaticiens à passer leur vie à tenir à jour tous les logiciels utilisés.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: PPA pour Debian?
Posté par Bernez . Évalué à 4.
Le problème c'est qu'il existe tout un tas d'entreprises (et même de geeks adeptes de l'autohébergement) qui sont utilisatrices d'applications web, mais dont le développement web n'est pas la cœur de métier et qui préfèrent avoir une version stable et sécurisée plutôt qu'une version « au summum de la modernité ».
Même quand elles sont empaquetées par les distributions, les applications web sont exécutées par l'intérmédiaire d'un serveur web qui tourne sous un utilisateur dédié (qui n'est pas forcément le même entre toutes les applications web). Le fait que les fichiers soient stockés dans un sous-répertoire de /usr/share et appartiennent au root ne diminue pas la sécurité.
[^] # Re: PPA pour Debian?
Posté par gnumdk (site web personnel) . Évalué à 5.
Au contraire, parce que les mecs qui font du:
chown -R www-data. /var/www/monappli
chown -R 700 /var/www/monappli
Et qui se sentent en sécurité…
[^] # Re: PPA pour Debian?
Posté par reynum (site web personnel) . Évalué à 2. Dernière modification le 22 décembre 2016 à 11:39.
C'est
chmod 700 _list_of_files_sinon on se retrouve dans un cas typique de "yaplurienkimarche"kentoc'h mervel eget bezan saotred
[^] # Re: PPA pour Debian?
Posté par windu.2b . Évalué à 3.
Y a un truc que je ne comprends pas, dans la discussion ci-dessus :
{own|next}cloudn'est pas la première application Web/CMS à être packagée, quand même… Comment ça se passe, pour d'autres commephpmyadmin(pour n'en citer qu'une, connue et hautement sensible aux failles) ?[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: PPA pour Debian?
Posté par windu.2b . Évalué à 2.
25/11 ? Ah oui…
(bon, après je me rends pas bien compte si c'est plus lent que la normale, ou pas).
[^] # Re: PPA pour Debian?
Posté par Misc (site web personnel) . Évalué à 3.
Tu peux préciser "gestion des dépendances" (car mine de rien, ça commence à tirer des paquets de partout), et "installation saine". Par installation saine, je veux dire "sans que le serveur web puisse modifier son propre code car il a le droit d'écrire sur son dossier", par exemple.
Le fait aussi de placer ça au bonne endroit permet de s'assurer que selinux donne les bons labels (même si je reconnait qu'on est loin de ce qu'on pourrait faire à ce niveau la).
Et tu as aussi le fait de pouvoir vérifier ce qui est installé (rpm -Va, debsums).
Et la vérification que la licence est correct aussi.
[^] # Re: PPA pour Debian?
Posté par Zenitram (site web personnel) . Évalué à 0.
OK. Mais comme des "applications Web ou des CMS" c'est exactement comme des "application pas Web et pas CMS" dans la façon de travailler (certains sont stables, d'autres pas stables, web ou pas, c'est orthogonal), ça veut dire que tu ne vois que des inconvénient au gestionnaire de paquet pour tout.
Comme les autres applications donc.
Avec les mêmes problèmes (failles de sécu non patchées etc)
Faut arrêter le délire : "Web/CMS", c'est pas ça qui fait que ça bouge ou pas. Beaucoup de choses bougent, d'autres ne bougent pas, quelque soit le domaine.
Ici, tu flingues l'idée d'un repo pour toute application, car le monde bouge, mais pas que "Web/CMS.
Et les avantages de mettre du "Web/CMS" dans les repos sont les mêmes que pour les autres applications.
Faudrait donc savoir : on m'avait dit que la force de Linux était aussi dans les repos, et là on me flingue les repos, désolé mais je suis perdu, j'entends tout et son contraire (les repos c'est génial, ha ici on me dit que ça pue).
[^] # Re: PPA pour Debian?
Posté par barmic . Évalué à 4.
Oui pour moi ce qui fait la différence, c'est que je préfère configurer moi-même mon serveur web et j'ai jamais pris le temps de découvrir comment est-ce que les packageurs configure le soft pour ensuite le déconstruire. Je ne sais même pas si les paquets ont des conf pour nginx et s'ils ne vont pas tirer un apache par défaut.
Je pense que la solution pour que je me mette à utiliser les paquets c'est surtout qu'il soient tous lancé comme un service avec leur propre serveur local que je puisse garder mon nginx comme reverse proxy pour contrôler ce qui est exposé et comment est-ce que ça l'est.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: PPA pour Debian?
Posté par Misc (site web personnel) . Évalué à 2.
Ce qui permettrais aussi de les faire tourner avec un user différent et des privilèges non partagés. Et ce qui est le fonctionnement de tout faut mod_php, sauf erreur de ma part.
Ce qui permet aussi d'isoler les crashs à une application, etc, etc.
Et de séparer l'espace mémoire du truc avec la clé ssl de l'espace mémoire du truc avec du code complexe qui tourne.
[^] # Re: PPA pour Debian?
Posté par Maclag . Évalué à 8.
J'ai volontairement enlevé le premier paragraphe, et je me rends compte que tu peux écrire ça pour tout projet actif, même (surtout?)… le noyau Linux!
Oui ben comme le reste des applis du système, faut suivre la politique de la distro.
Firefox aussi, et plein d'autres. Tu préfèrerais des mises-à-jour comme à la bonne époque Win95--Win7? Chaque appli fait sa tambouille?
# continuous delivery
Posté par Anonyme . Évalué à -1.
C'est peu ou prou la raison pour laquelle docker n'est pas présent dans les dépôts debian non plus.
L'usage tends désormais à ce que les outils qu'on utilise évoluent rapidement, et je pense que les distributions devraient plus se segmenter pour se concentrer d'avantage sur un socle de base que sur la distribution de logiciels qui deviendront obsolètes quelques mois après la publication.
Une bonne distribution, ça devrait être un système d'init, un serveur d'affichage, quelques drivers, des librairies dont on peut facilement faire cohabiter les versions et des environnements de desktop. Le reste ça devrait être laissé à la communauté, fournir des outils de packaging pour permettre aux développeurs de distribuer facilement leurs applications, etc.
[^] # Re: continuous delivery
Posté par Glandos . Évalué à 10.
Ahah.
Oui, moi aussi, j'aime passer mes soirées et mes week-end à mettre à jour toutes mes applications web, parfois à coup de
git pull, parfois à coup detar xf, mais faut fusionner la configuration après. Oh, et puis parfois, les dépendances installées en tant que paquets du système ne sont plus à jour, mais ça, je ne peux pas le savoir avant d'avoir exécuté le code.J'ai failli oublier : les FAILLES DE SÉCU. Je répète : je fais confiance à ma distribution pour se mettre à jour dans un temps relativement court. Les 14 dépôts de logiciels qui ne sont pas inclus dans ma distribution, je fais comment ?
Oui, j'installe des applications à la main. Mais je préfère quand c'est empaqueté, comme roundcube par exemple. Même si parfois, ça pète.
[^] # Re: continuous delivery
Posté par barmic . Évalué à 5.
Je ne suis pas d'accord. Mais oui il y a un besoin différent de ce qui est généralement proposé.
Personnellement je pense qu'avoir 2 segments, un base system et un arbre de port, qui ont des cycles de vie différents, me plairait bien. On peut considérer que c'est ce que arch propose avec tous le(s) dépôt(s) accessibles via yaourt comme arbre des ports (et dont la qualité est bien moins réputée…) ou debian avec updates ou backport, mais dont les contraintes d'intégrations sont aussi importantes que pour le reste des dépôts Debian.
Au final, il n'y a pas vraiment de solution, il faut faire des choix les distributions en font. Certaines comme ubuntu ou fedora, préfèrent proposer un cycle de release court (c'est pas forcément idiot non plus).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: continuous delivery
Posté par gnumdk (site web personnel) . Évalué à 2. Dernière modification le 19 décembre 2016 à 16:38.
Puis y'a le problèmes inverses, les applications liées à un OS… Ici, on a des projets qui utilisent encore Debian 6, voir même Debian 5, voir même (Oh merde) Debian 4!
Comme quoi, les distribs avec un cycle très long c'est important :)
[^] # Re: continuous delivery
Posté par Nico C. . Évalué à 7.
Oui bien sur… et après, y'a des problématiques de dépendances sans aucun controle, des milliers de packages morts sans suivi, des packages tout en haut de la pyramide de dépendances qui disparaissent/changent de nom/sont abandonnés à cause de l'égo d'un seul dev, etc
Bref, ça devient la même grosse merde que chez npm et d'autres… Ca serait juste un retour en arrière de 20 ans.
A partir du moment ou on autorise les dépendances alors le packaging doit être une dictature centralisée. Je vois pas d'autre solution. Sinon, on fait une distrib ou chaque appli fait ce qu'elle veut n'importe comment et embarque la totalité de ses dépendances dans un container de 300Mo et vogue la galère.
Je crois que ça existe déjà mais ça reste plutot confidentiel…
[^] # Re: continuous delivery
Posté par totof2000 . Évalué à 3.
Bah, c'est comme ça que ça se passe pour les xBSD depuis longtemps. Il y a eu parfois des problèmes mais depuis quelques années ça marche plutôt bien.
[^] # Re: continuous delivery
Posté par Nico C. . Évalué à -3.
Ben ouais mais les références du Libre pour le monde pro, c'est RedHat et Debian. Y'a pas de xBSD…
Même Ubuntu est largement plus utilisé qu'un xBSD, c'est dire…
Enfin bon, c'est pas pour troller les xBSD, c'est juste un constat, hein…
# Comment a fait Mageia
Posté par ʭ ☯ . Évalué à 2.
Comme je me suis retrouvé à maintenir ce paquet dans Mageia, voici comment on a décidé de faire :
- Owncloud 8.0.x dans les mises à jour de sécurité de Mageia 5
- Owncloud 8.1.9 et 8.2.8 et 9.0.5 dans le média des rétroportages (backports) pour les utilisateurs qui veulent préparer le passage en Mageia 6
Mageia 6 ne contiendra que Nextcloud 10.x.y.
Et pour tout ça, une page de Wiki pour que l'utilisateur aie des pistes sur quoi faire.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Comment a fait Mageia
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
Pourquoi n'en garder qu'un? Et pourquoi NextCloud dans ce cas?
[^] # Re: Comment a fait Mageia
Posté par ʭ ☯ . Évalué à 3.
On n'en garde qu'un, parce que les mises à jour de sécurité c'est beaucoup de travail, et qu'on n'a pas les moyens de les faire pour les deux.
Nextcloud tient d'ores et déjà sa promesse des mises à jour facilitées, avec possibilité de sauter la version 10.0. C'est donc le candidat choisi.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Comment a fait Mageia
Posté par Bruce Le Nain (site web personnel) . Évalué à 3.
Merci :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.