Par défaut, toujours installer les paquets recommandés (Debian)

Par Carl Chenet. Suivez-moi sur Identi.ca à http://identi.ca/carlchenet

Je réagis au billet de toitoinebzh : Apt-get : installation sans paquets recommandés.

Si ces paquets sont recommandés par le mainteneur du paquet en question, c’est qu’ils apportent quelque chose à ton application 🙂
Bien souvent en n’installant pas les paquets recommandés, tu ne vas pas pouvoir profiter de fonctionnalités annexes de l’application. En gros tu installes le strict minimum et tu devras installer plus tard ce qui te manque de toute façon si tu viens à utiliser ces fonctionnalités. Reste à comprendre dans le futur pourquoi tu ne peux pas utiliser ces fonctionnalités, ce qui peut poser problème.
Donc à moins d’être dans un environnement à l’espace disque réduit et dans le cadre duquel il est important d’économiser de l’espace et que l’on sait exactement ce que l’on fait avec son application, les paquets recommandés sont toujours à installer.
Publicités

8 réflexions au sujet de « Par défaut, toujours installer les paquets recommandés (Debian) »

  1. Le problème vient du fait que certaines recommandations ne sont pas du tout pertinentes et devraient être des suggestions.
    Exemples concret : mysql-server recommande mailx ou mutt qui recommande exim4.

  2. @Jokernathan : Si tu trouves une recommandation que tu trouves abusive et que tu souhaiterais la voir passer en suggestion, n’hésite pas à ouvrir un rapport de bug à l’aide de reportbug afin de signaler ce problème. Tu avertis ainsi le mainteneur du problème et tu auras son point de vue.

  3. chaica : malheureusement on en revient souvent au même problème : pour moi c’est tellement pénible de configurer reportbug sur chaque serveur que je me contente d’un « –without-recommends » en cas d’âneries.

    Une parmis tant d’autre : « dkimproxy » qui recommande « amavis », alors que pour moi ça n’a rien à voir avec la choucroute… surtout dans le cas où on utilise dkimproxy avec exim4, le MTA par défaut.

  4. Olivier B. : Dans les cas d’un serveur tu peux très facilement exporter ta configuration en utilisant le fichier de configuration ~/.reportbugrc que tu as généré lors de ta première utilisation de reportbug. Tu peux le placer en tant que /etc/reportbug/reportbug.conf afin que tous les utilisateurs bénéficient des mêmes configurations.

    Si tu constates un problème, il faut le signaler, sinon il est certain qu’il ne pourra pas être corrigé.

  5. La copie du « .reportbugrc » ça implique d’y stocker le mot de passe de connexion SMTP ou bien de le mémoriser. Dans mon cas, aucune de ces deux solutions ne me convient, tout comme il m’est impensable de whitelister toutes les machines en question sur mon serveur SMTP.

    Je radote, mais pour moi l’obligation du passage par email pour le rapport de bug n’est clairement pas la bonne solution. Ca pourrait très bien accepter aussi les soumissions par HTTP ou autre protocole, quitte à faire valider l’adresse email (comme pour le suivi des commentaires sur ce blog par exemple).
    Mais avec toutes les entraves faites aux emails actuellement (ports standards bloqués, SPF, DKIM, et autres joyeusetées), continuer à imposer le SMTP comme seul moyen de rapport de bug me semble hallucinant.

    Et je précise au cas où que je serais même prêt à développer/tester/héberger la passerelle en question si besoin (et non, je ne suis pas un partisan du « full-http », au contraire).

  6. Je sais bien, j’avais d’ailleurs réagis en ce sens aussi. C’est pourquoi j’indiquais que je « radote ».

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s