Journal Owncloud viré de Debian

Posté par (page perso) . Licence CC by-sa.
Tags : aucun
14
18
déc.
2016

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 (page perso) . É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 (page perso) . Évalué à 10. Dernière modification le 19/12/16 à 03:02.

      Il n'y a aucun paquet nextcloud dans Debian à l'heure actuelle (y compris dans unstable/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 (page perso) . Évalué à 10.

        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)

        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. :-/

        Il n'y a aucun paquet nextcloud dans Debian à l'heure actuelle […]
        ça ressemble à une occasion manquée

        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 . Évalué à 8.

          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. :-/

          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 (page perso) . Évalué à 10.

          En tous cas, c'est toujours triste de lire ce type de mésententes. ;-(

          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 (page perso) . Évalué à 7. Dernière modification le 19/12/16 à 15:19.

            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.

            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 (page perso) . Évalué à 2.

      elle n'est pas neuve celle-la

      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 . É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 . É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 . É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 (page perso) . Évalué à -4.

    Un jour il va falloir que quelqu'un fasse un hosting PPA pour Debian.

    • [^] # Re: PPA pour Debian?

      Posté par . Évalué à 6.

      Je ne vois aucun avantage à avoir des paquets pour des applications Web ou des CMS. Je n'y vois même que des inconvénients.

      Ces application évoluent rapidement et doivent être très fréquemment mises à jour pour corriger des failles de sécurité. À moins que le mainteneur du paquet assure une mise à jour quasiment en continu, on risque fatalement de se retrouver avec une application présentant des failles.

      De plus ces applications s'installent systématiquement dans /var/www/html et placent souvent des fichiers de configuration dans /etc/default et autres, ce qui ne correspond pas forcément aux choix de l'administrateur système.

      Il me semble beaucoup plus efficace d'installer ces applications à partir de leurs sources dans le dossier de son choix et en ajustant les fichiers de configuration soi-même. D'autant que Nextcloud, par exemple, propose maintenant son propre système de mise à jour fonctionnel.

      • [^] # Re: PPA pour Debian?

        Posté par . Évalué à 9.

        Ces application évoluent rapidement et doivent être très fréquemment mises à jour pour corriger des failles de sécurité.

        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 . Évalué à 2.

          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?

          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 . Évalué à 10.

        Je ne vois aucun avantage à avoir des paquets pour des applications Web ou des CMS.

        Ç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é.

        De plus ces applications s'installent systématiquement dans /var/www/html et placent souvent des fichiers de configuration dans /etc/default et autres, ce qui ne correspond pas forcément aux choix de l'administrateur système.

        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).

        D'autant que Nextcloud, par exemple, propose maintenant son propre système de mise à jour fonctionnel.

        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.

        • [^] # Re: PPA pour Debian?

          Posté par . Évalué à 1.

          Ce que tu dis est tout à fait pertinent, mais pas dans le cas d'applications web.
          Personnellement je préfère avoir la dernière version majeure de l'application plutôt qu'une version plus ancienne patchée au fur et à mesure.

          Le choix de l'emplacement d'installation n'est pas aussi simple. Comme elles sont justement souvent affectées par des problèmes de sécurité, on a pas forcément envie de voir tous les scripts sous /usr/share appartenant à root. Si une faille est exploitée avec une injection de code les dégâts risquent d'être beaucoup plus importants que si l’application est dans son propre dossier, les scripts appartenant à un utilisateur spécifique avec des droits limités au strict nécessaire.

          Évidemment le travail de maintenance s'en trouve accru, mais il y a souvent la possibilité d'automatiser les mises à jour.

          • [^] # Re: PPA pour Debian?

            Posté par . Évalué à 4.

            Personnellement je préfère avoir la dernière version majeure de l'application plutôt qu'une version plus ancienne patchée au fur et à mesure.

            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é ».

            on a pas forcément envie de voir tous les scripts sous /usr/share appartenant à root. Si une faille est exploitée avec une injection de code les dégâts risquent d'être beaucoup plus importants que si l’application est dans son propre dossier, les scripts appartenant à un utilisateur spécifique avec des droits limités au strict nécessaire.

            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 (page perso) . Évalué à 5.

              de /usr/share et appartiennent au root ne diminue pas la sécurité.

              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 (page perso) . Évalué à 2. Dernière modification le 22/12/16 à 11:39.

                chown -R 700 /var/www/monappli

                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 . Évalué à 3.

            Y a un truc que je ne comprends pas, dans la discussion ci-dessus : {own|next}cloud n'est pas la première application Web/CMS à être packagée, quand même… Comment ça se passe, pour d'autres comme phpmyadmin (pour n'en citer qu'une, connue et hautement sensible aux failles) ?

        • [^] # Re: PPA pour Debian?

          Posté par (page perso) . Évalué à 3.

          Ç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é.

          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 (page perso) . Évalué à 0.

        Je ne vois aucun avantage à avoir des paquets pour des applications Web ou des CMS. Je n'y vois même que des inconvénients.

        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.

        Il me semble beaucoup plus efficace d'installer ces applications à partir de leurs sources dans le dossier de son choix et en ajustant les fichiers de configuration soi-même.

        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 . Évalué à 4.

          Faut arrêter le délire : "Web/CMS", c'est pas ça qui fait que ça bouge ou pas.

          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 (page perso) . É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 . Évalué à 8.

        Ces application évoluent rapidement et doivent être très fréquemment mises à jour pour corriger des failles de sécurité. À moins que le mainteneur du paquet assure une mise à jour quasiment en continu, on risque fatalement de se retrouver avec une application présentant des failles.

        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!

        De plus ces applications s'installent systématiquement dans /var/www/html et placent souvent des fichiers de configuration dans /etc/default et autres, ce qui ne correspond pas forcément aux choix de l'administrateur système.

        Oui ben comme le reste des applis du système, faut suivre la politique de la distro.

        Il me semble beaucoup plus efficace d'installer ces applications à partir de leurs sources dans le dossier de son choix et en ajustant les fichiers de configuration soi-même. D'autant que Nextcloud, par exemple, propose maintenant son propre système de mise à jour fonctionnel.

        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 . É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 . É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 de tar 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 . É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 (page perso) . Évalué à 2. Dernière modification le 19/12/16 à 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 . Évalué à 7.

      Le reste ça devrait être laissé à la communauté, fournir des outils de packaging pour permettre aux développeurs de distribuer facilement leurs applications, etc.

      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 . Évalué à 3.

        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

        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 . É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 (page perso) . É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

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.