slackware 9.0 beta

Posté par  (site web personnel) . Modéré par Manuel Menal.
Étiquettes :
0
3
sept.
2002
Slackware
Alors que l'on aurait pu penser que la slackware 9.0 serait très longue à venir, la 9.0 bêta est déjà là...

Au programme : utilisation de gcc 3.2 (d'où le passage au 9), mise à jour de nombreux packages, entre autres Linux 2.4.19, KDE 3.0.3, mais toujours pas de Gnome 2.

PS: je rajoute un lien vers mon projet (des ports "à la" *BSD pour slackware:) pour ceux qui sont intéressés).

Aller plus loin

  • # heu, et les slaktools ?

    Posté par  . Évalué à 10.

    Il existe également un autre projet que les slackports; bien plus avancé AMHA; qui permet à notre slack depuis la 8.0 de gerrer les dépendances.

    http://slaktools.sf.net(...)

    J'ai été personnelement déçu par les slackports qui n'apportent pas grand chose aux pkgtools déjà existants (si ce n'est rien...).

    Ce qui m'étonne de la part de pat dans cette 9.0, c'est qu'il n'a (pour le moment) pas encore modifiés les pkgtools depuis la 8.1. Donc on serait donc repartis pour une 9.0 sans aucune avancée dans le système de packaging.

    bon pour ceux qui veulent jeter un coup d'oeil au changelog c'est là:

    http://www.slackware.com/changelog/current.php?cpu=i386(...)

    • [^] # Re: heu, et les slaktools ?

      Posté par  . Évalué à 10.

      http://slaktool.sf.net/(...)

    • [^] # Re: heu, et les slaktools ?

      Posté par  (site web personnel) . Évalué à 10.

      le but de slackports n'est pas d'apporté des nouvelles fonctionnalitées à pkgtool, mais de pouvoir utilisé les ports *BSD et de gérer les dépendances pour les ports, et de créer un tree avec des ports qui permetteront de toujours avoir un système complètement a jour sans pour autant se prendre la tete.

      Mais il est vrai que slackports n'est pas encore très évolué, mais le projet n'a que 1 moi donc voila...
      Mais la version 0.3 devrait sortir d'ici peu, et il y a un ROADMAP qui permet de connaitre les fonctionnalitées qui vont etre implémentée.

      De plus une utilisation de slacktools, n'empeche en rien l'utilisation de slackports.

      • [^] # Re: heu, et les slaktools ?

        Posté par  . Évalué à 4.

        là, il me semble que l'on a un GROS problème.

        On a des pkgtools officiels, qui marchent bien, mais qui pourraient quand même être améliorés.

        On a des slaktool(s) qui ont étés lancés par slackware pour gérrer les dépendances, qui marchent super bien mais qui ne seront probablement jamais utilisés par pat.

        Enfin on a les slackports, qui viennent de naitre, qui comptent faire comme les slaktools, mais avec une compatibilité avec les BSD...

        Je sais pas vous, mais j'ai la désagréable sensation d'un immense gachi de travail et de temps qui ne servira à rien ou qui pourrait servir, mais qui ne servira pas (et on sait pas pourquoi...)

        alors qu'aujourd'hui plus que jamais, slackware aurait besoin de mettre son système de packaging à jour!

        -1 parce que désolant !

        • [^] # Re: heu, et les slaktools ?

          Posté par  (site web personnel) . Évalué à 10.

          slackports n'est pas un système de package
          c comme les ports de freebsd : y a les ports et le système de package, slackports c'est les ports, il s'appuie sur pkgtool pour créer ces packages, mais n'est pas fait pour le remplacé, ni l'améliorer, les but est de télécharger, compiler et installer des softs en créant des packages slackware (avec makepkg), les installant avec installpkg, de manière a pouvoir les manipuler avec pkgtool.

          que slacktool soit un system pour remplcé pkgtool ok, mais slackports ne l'est pas, et n'a pas du tout pour vocation de remplacer pkgtool, au contraire.

          Si slackports va gérer les dépendances, c'est pas pour permettre de rajouter une fonctionnalité qui n'existe pas encore sur pkgtool, mais pour que les compilation se passent sans problème.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 0.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: heu, et les slaktools ?

            Posté par  (site web personnel) . Évalué à 3.

            > Pas du tout : il s'agit d'une initiative indépendante développée "à part" par des dévellopeurs qui ne sont pas du tout liés à Linux Slackware (si ce n'est qu'ils en sont fans, je suppose).

            Si, les slaktools étaient le projet officiel de la slack pour améliorer le systeme de package. Il a été abandonné puis quand pat a été prévenu qu'il avait été repris, il n'en a rien eu a faire.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 0.

              Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: heu, et les slaktools ?

      Posté par  . Évalué à 10.

      Pour Slaktool, le projet n'a pas l'air très vivant. Pas de news depuis octobre 2001, le CVS n'a pas été touché depuis cette époque-là, et les seuls messages présents sur la ML en 2002 sont du SPAM...

      • [^] # Re: heu, et les slaktools ?

        Posté par  . Évalué à 10.

        Cedric (le developpeur des slaktools) m'avait expliqué que pat comptait déveloper son propre système de dépendances pour la 9.0... (qu'en est-il?)

        Ce que je veux dire c'est que quand tu as fait un bon boulot, que tu le fais savoir et qu'on te dis NON, on préfère faire le notre... ben la motivation n'est plus au beau fixe!

    • [^] # Re: heu, et les slaktools ?

      Posté par  (site web personnel) . Évalué à 10.

      Le probleme avec la slack, c'est que le systeme de package est vraiment dépassé. Pat pourrait mettre a jour les pkgtools, mais ça ne servirait a rien. Elle a prit beaucoup de retard par rapport aux autres distros. Quand on voit la facilité d'installation d'un package avec une debian ou une mandrake, la slack est loin derriere. Ça fait des années que j'utilise la slack et je n'avais jamais remarqué ce manque jusqu'a ce que j'essaye véritablement apt-get et urpmi.

      Une bonne solution serait d'utiliser un systeme de package different, en créer un nouveau serait stupide et prendrait trop de temps, apt ou urpmi seraient de bons candidats mais les utilisateurs de slack crieraient au scandale. Les ports a la bsd sont une bonne idée, mais il vaudrait mieux un véritable portage plutot que cet infâme script shell qu'est slackports.

      • [^] # Re: heu, et les slaktools ?

        Posté par  (site web personnel) . Évalué à 10.

        infame, infame, soit gentil quand meme :)

        Slackports sera un vrai system de ports avec des makefile et tout a partir de la version 0.5,
        Le script existera toujours pour ceux qui voudront l'utilisé, mais il sera épuré.
        Il aura son propre tree mais pourra tout aussi bien utilisé celui des BSD.

        Le script comme celui actuel permettait en fait de pouvoir sortir rapidement quelque chose de fonctionnel et de pouvoir avoir rapidement des avis sur les fonctionnalité qui devaient faire partie d'un tel système.

      • [^] # Heu, et les slaktools ? et les slackports ? et .................................

        Posté par  . Évalué à 0.

        Heu le infame à moins que t'ais quelque chose de mieux ou meme quelque chose tout court à proposer tu pourrais eviter.
        Sois deja content qu'il le fasse en GPL et pas avec une license fermée.
        Tu fais mieux ? Moi non, donc je la ferme ou j'encourage (j'en profite pour encourager).
        Bon voila c'etait histoire de gueuler un peu ca soulage.

        Quand au systeme de package de la Slack il est tres bien sans dependances, ca permet de bien savoir ce qu'on fait, enfin ca force :-) et en plus ca permet de faire un systeme sans bash et juste avec ash si t'as envie (par exemple).
        Et puis ca m'enerve un peu tout ce monde qui critique sans rien faire. T'en as au moins envoyé une liste de tes idées aux gars qui se casse le cul à faire slacktool et slackports ????

        Moi je voulais faire une derivée slack optimisée pour serveur perso==>> resultat rien !
        Mais au moins je critique pas inutile.
        Par contre des que je peux je publie un package xinetd qui est plus sympa que inetd.

        Bon voila je vais dormir j'ai la creve

        • [^] # Re: Heu, et les slaktools ? et les slackports ? et .............................

          Posté par  (site web personnel) . Évalué à 7.

          > Heu le infame à moins que t'ais quelque chose de mieux ou meme quelque chose tout court à proposer tu pourrais eviter.
          > Sois deja content qu'il le fasse en GPL et pas avec une license fermée.
          > Tu fais mieux ? Moi non, donc je la ferme ou j'encourage (j'en profite pour encourager).

          Pourquoi vouloir a tout prix recréer qqch de neuf? Comme je l'ai déja dit un peu plus haut, apt-get et urpmi sont assez matures pour etre utiliser.

          C'est vrai, parfois, ça a des avantages de gérer soit même les dépendances, mais ces cas sont tres rares et la plupart du temps, c'est juste psychologique pour pouvoir se dire qu'on sait le faire. Y a pas longtemps, j'ai vu un utilisateur de slack qui voue un véritable haine au debianniste, il se croit supérieur parce qu'il fait tous à la main.

          • [^] # Re: Heu, et les slaktools ? et les slackports ? et .............................

            Posté par  (site web personnel) . Évalué à 10.

            >j'ai vu un utilisateur de slack qui voue un véritable haine au debianniste, il se croit supérieur parce qu'il fait tous à la main.

            Y a des abrutits partout.

            >Pourquoi vouloir a tout prix recréer qqch de neuf?

            Pour repenser un système qui peut etre sera mieux, pour moi dans ces cas il faut pouvoir garder une compatibilité avec quelque chose de déjà éxistant pour assusrer la pérénité du nouveau projet.

            C'est ce que j'essaye de faire avec slackports, les ports à la BSD fonctionne bien et donc pour slackports, j'essaie d'arriver au meme genre de résultat, et pour cela je vise la compatibilité totale, mais j'essaie de le faire autrement, on ne sait jamais des fois que j'aurais trouvé l'idée du siècle :)

            Après c'est mon point de vue du truc, je me trompe peut etre, mais dans beaucoup de cas c'est ce qui fait que le monde linux est ce qu'il est : regarde le nombre de distrib qu'il y a aujourd'hui, chacun en trouve une a son gout, pourtant globalement ça reste du linux, si ils avaient tous suivi ton raisonnement il n'y aurait qu'une distrib et tant pis pour ce a qui elle plait pas...(bien sur se mode de fonctionnement a aussi ces inconvénients : trop de diversité, il est plus difficile pour un newbie de s'y retrouver, et plein d'autres inconvénients encore...)

          • [^] # Re: Heu, et les slaktools ? et les slackports ? et .............................

            Posté par  (site web personnel) . Évalué à 3.

            un véritable haine au debianniste

            Ah bon il reste plus qu'un debianniste ? ;)

            L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

          • [^] # Re: Heu, et les slaktools ? et les slackports ? et .............................

            Posté par  . Évalué à 1.

            Ben non.
            En l'occurence, c'est un très bon moyen pour maitriser totalement ce qui est sur ton système.
            De plus, un système gérant les dépendances n'a de sens que si tu n'installes que des packages adaptés. Si tu commences à installer des sources, alors ton système de dépendances n'a plus de sens.
            Personnellement, que ce soit avec la Mandrake ou avec la Debian, les dépendances ont toujours fini par être plus une nuisance qu'un avantage.
            C'est pour cela que j'utilise la Slackware et je serais fort marri qu'il change de façon de faire.

            Cordialement,

            • [^] # Re: Heu, et les slaktools ? et les slackports ? et .............................

              Posté par  (site web personnel) . Évalué à 2.

              Dans ce cas utilise un systeme à la NetBSD cad le beurre et l'argent du beurre :
              Si tu veut pas te faire chier : des paquets binaires .
              Si tu veut compiler : make (les dependances sont gerées) et tu as toujours un systeme cohérent.
              Ton soft préferé n'existe pas encore, ou dans une version + ancienne : creer un nouveau paquet est à la portée de n'importe qui en moins de 10 mn (plus le temps de compile) !

    • [^] # Pitié, pas de packages "avancés"

      Posté par  . Évalué à 6.

      Si Volkerding est comme moi, il ne changera rien à son système de packaging : c'est parceque qu'il ne gérai pas les dépendances que je suis venu à utiliser la Slack, en ayant marre des systèmes la 'gérant', ou tu ne peux plus installer des sources compilées sans casser complètement justement la base de dépendance.
      Les packages qui gèrent la dépendance sont bien pour des distributions ou tu ne vas installer que des packages officiels ou certifiés.
      En pratique, j'ai toujours trouvé que c'était finalement plus une nuisance qu'un avantage.

      Cordialement,

      • [^] # Re: Pitié, pas de packages "avancés"

        Posté par  (site web personnel) . Évalué à 4.

        C'est aussi une des raisons principales qui me fait rester sur Slack. Si elle passait à un système de package "à la Debian" par défaut, je pense que je passerai au LFS. Pour moi, la Slack est une LFS de feignasses (comme moi) qui ne veulent pas se prendre la tête à _tout_ installer à la main.

  • # Slack c'est commercial maintenant ?

    Posté par  . Évalué à 10.

    Je vais encore prendre des [-], mais je voulais quand même savoir : c'est quoi cette version 9.0 bata ?
    Ça existe en 44 ?

    • [^] # Re: Slack c'est commercial maintenant ?

      Posté par  (site web personnel) . Évalué à 2.

      Non pas encore mais tu peux upgrader tes batas via slakports pour changer de pointures :)

      PS : attention un jeu de mots ridicule se cache dans ce poste. Saurez-vous lee retrouver ?

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # precisions

    Posté par  . Évalué à 0.

    d'abord c'est ne pas une beta mais seulement le début et donc seulement la création du nouveau current
    En effet je pense que la verification que le programmes sont compatible avec gcc3.2 va etre longue
    donc pour l'instant il y a la base Xfree et kde compile avec gcc3.2
    sinon pour gnome le probleme vient de freetype et
    pango
    personnellement j'ais reussi a insttaller gnome2.0.1 sur une 8.1
    </troll> il est beaucoup plus rapide que KDE3.0.1
    <troll>

    • [^] # Re: precisions

      Posté par  (site web personnel) . Évalué à -1.

      </troll> [...] <troll>

      Serait-ce une tentative de Troll inversé ?

      Bon, je sais -1, mais avouez quelle était facile !!!

Suivre le flux des commentaires

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