Migration Linux à Windows

Kevin Denis <kevin@nowhere.invalid> a écrit :

Le 23-07-2007, Raphaël 'SurcouF' Bordet <surcouf@debianfr> a écrit :

Parce qu'on n'en a pas besoin : dpkg est là pour remplir ce rôle.

Bon, j'ai appris que dpkg -L me liste le contenu d'un paquet. Mais
maintenant, comment connaitre le nom du paquet lorsqu'on a un
fichier? Au hasard, dpid, c'est dans quel paquet?

mauvais hasard, changer de hasard...

Si tu as une infinité de temps devant toi, statistiquement, tu vas
trouver la solution...

Sinon, *une* solution est apt-find... il y a plein d'autres ;..

PK

--
      |      _,,,---,,_       Patrice KARATCHENTZEFF
ZZZzz /,`.-'`'    -.  ;-;;,_   mailto:p.karatchentzeff@free.fr
     |,4-  ) )-,_. , (  `'-'  http://p.karatchentzeff.free.fr
    '---''(_/--'  `-'_)       

On Tue, 24 Jul 2007 10:32:20 +0000 (UTC), Kevin Denis wrote:

Tant pis, on ne supporte pas Slack (et personne ne s'en plaint).

Qui est le 'on' ? Et de quel support parles tu?

« on » c'est différentes équipes de développement que je dirige ou
dont je fais partie et qui ont des build farms.

De toute façon devant les outils Slackware je ne peux que m'énerver,
c'est dommage. Par exemple je n'ai jamais réussi à lancer une commande
sous l'id d'un utilisateur qui n'a pas de shell. Par exemple sur ma
Debian je fais "su -s /bin/sh ftp -c id" ; sous Slackware cette syntaxe
n'a jamais fonctionné. Ça a peut-être changé depuis, je ne sais pas.

kevin@zipslack:~$ man su | grep -- "-s"

kevin@zipslack:~$
Ceci dit:
/usr/doc/shadow-4.0.3/WISHLIST:- su -l, -m, -p, -s options (as in GNU su)
- done in the Debian patches

donc a ce que je comprends, ce sont des options qui existent dans les
patchs debian, et qui sont en WISHLIST...
(le man cite aussi que su depend beaucoup des options de compilation,
il faudrait aller voir le slackbuild pour verifier)

Euh, n'importe quoi. Ce ne sont absolument pas des patches dans GNU
su, c'est d'origine. Et c'est maintenant dans shadow su aussi, je ne
comprends pas trop pourquoi tu as la version 4.0.3 (sortie il y a plus
de 3 ans et demi) alors qu'il y a une release tous les trois mois.

Pourtant, sur Google, 80 000 occurrences de var/lib/dpkg/info contre
18 000 occurrences de var/log/packages.

Quand on connait, oui. Mais j'ignorais meme que les paquets
avaient la liste des fichiers le composant dans un fichier plat.

Hum, je me demande bien dans quoi tu pensais que c'était stocké.

On reprend dpkg? Lors d'un dpkg -l le nom des paquets est tronque pour
que les infos tiennent sur 80 colonnes. Pour des paquets
comme openoffice, le nom est un peu long et on ne voit pas la
bonne info. On agrandit le xterm, on retape dpkg -l. C'est toujours
limite a 80 colonnes.

Mais n'importe quoi. Je suis désolé mais soit tu mens délibérément,
soit tes informations sont vieilles de 10 ans, soit tu es de super
mauvaise foi. La plus vieille Debian que j'aie ici sous la main est une
Debian potato (sortie il y a 7 ans) et dpkg ne se comporte pas du tout
tel que tu le prétends. Quand on agrandit le xterm, la sortie est remise
en page comme il faut.

On tape confiant
dpkg --help ou dpkg -<tab> et ... rien. La solution passe par
une variable d'environnement COLUMNS. Une variable d'environnement!
Pas une option, pas automatiquement, hein. Mais honnetement, ca te
parait simple? Serieusement? Pourquoi ca ne choque aucun dev
debian de devoir utiliser cette methode? Pourquoi ne pas utiliser
celle ci:
dpkg regarde la taille du terminal et adaptes les colonnes selon.

C'est exactement ce que fait dpkg depuis au moins 7 ans. Tu psychotes
pas un peu ?

Pour le nouveau, ca marche, il agrandit son xterm et il a son info.
Pour le power-user, on lui colle la variable COLUMNS s'il veut
afficher la sortie de dpkg en une largeur donnnee.

Non, le power user pas trop con qui connait le shell (comme tu
sembles l'attendre d'un utilisateur moyen) sait qu'il suffit de rajouter
|cat pour que la sortie standard d'un processus ne soit plus un
terminal.

Si je reprends slack, les paquets sont listables par un ls.

Sur Debian aussi : ls /var/lib/dpkg/info

Si je veux
trouver le plus vieux paquet installe, je lis le man ls. Et plus
tard, dans ma vie d'admin, ca me servira.

Alors souviens-toi de |cat qui risque de te servir dans ta vie
d'admin...

J'ai appris linux sur slack, j'ai bosse ensuite sur suze, redhat, debian
solaris et HPUX. Ce que j'ai appris sur debian m'a servi pour debian (et
fink sur mac OS X, mais c'est secondaire). Ce que j'ai appris sur
slack m'a servi partout, puisque j'ai appris a me servir de grep, tar,
awk, find, cut, etc, a lire des scripts shells, a chercher l'info etc..

C'est pas pour me moquer, mais si Slack t'a appris à chercher de
l'info vieille de plus de 7 ans à laquelle tu fais tellement confiance
que tu l'utilises pour argumenter sur Usenet, il y a peut-être un
problème (le problème pouvant très bien être que j'accorde trop de
crédit à une argumentation sur Usenet, bien entendu).

A l'opppose, seulement avec ce que je t'ai dit plus haut, tu devrais
etre capable de te debrouiller sur slack.

Bof, non. Ça ne me dit pas comment je bootstrape un chroot de Slack,
comment je sais si je dois recompiler mes programmes après avoir mis à
jour une bibliothèque, comment désactiver le serveur web en runlevel
4, comment passer de inetd à xinetd sans récrire ma config, et comment
avoir une Slack avec des softs à jour. Parce que shadow 4.0.3 dans la
Slack 12.0 sortie il y a 3 semaines, pardon encore, mais je rigole bien.

Pour les paquets, je pensais utiliser la gestion des paquets. Si je
reinstalle une librairie de cette maniere, comment va se comporter
le gestionnaire de paquet? Va t'il fonctionner ensuite?

Tu me fais penser à Eric S. Raymond qui vilipende Fedora parce que
"it's possible to inadvertently remove a shared library [...] and be
unrecoverably screwed". J'ai un scoop pour toi : quand tu fais une
connerie, que ce soit virer ta libc ou écrire 100 KB de zéros au début
de ton disque dur, tu l'as dans l'os. Si tu fais des conneries et que tu
veux un système qui soit simple à réparer quand tu as fait une connerie,
je te suggère http://www.bizz4all.com/m-catads+adsitem+ads_id-1020.html .

Sam.
--
echo "creationism" | tr -d "holy godly goal"

Dixit Sam Hocevar :

Quand on connait, oui. Mais j'ignorais meme que les paquets
avaient la liste des fichiers le composant dans un fichier plat.

Hum, je me demande bien dans quoi tu pensais que c'était stocké.

La base de registres, c'te question !

Nicolas George <nicolas$george@salle-s.org> writes:

Michel Billaud , dans le message <7zsl7fqfg9.fsf@serveur5.labri.fr>, a
écrit :

strace le-programme 2>&1 | grep open

strace -e open

Un jour je lirai la doc.

MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Raphaël 'SurcouF' Bordet wrote:

Méthode, dogme, tu peux lui attribuer le mot que tu veux, ça revient au
même. Je ne vois pas en quoi cela est fondamentalement différent.
Tu préfères « suivre » les méthodes préconisées par les développeurs ?
Parce que ça m'étonnerait que tu mettes tout dans /usr/local ou que le
fait de les placer dans /opt/<logiciel>/<versions> correspond à la fois
aux « standards » et aux procédures d'installations préconisées par les
développeurs. Avoue que cela est plutôt ...contradictoire.

Ca m'est arrive de mettre des choses dans /opt, quand ca allait avec
d'autres choses qui etaient la.

Apres tout, ce repertoire a du sens.

Personne ne t'a obligé à t'expatrier aussi loin de ton lieu de travail.
Évidemment, comme tu es le seul à maitriser tes méthodes, tu ne peux pas
déléguer aussi loin.

Mon probleme n'est pas de deleger, ca c'est pas tres complique, c'est de
reprendre ce que d'autres ont fait.

Mais qui donc installe ces Debian qui te tourmentent tant ?
Tes clients ?

Moi dans le passe, des religieux a droite et a gauche, des gens qui
croyaient bien faire, des gens qui ont pas trop mal fait non plus, des
gens qui ont fait ca par hasard (moi au debut, par exemple).

Stephane TOUGARD <stephane@unices.org> a écrit :

[...]

T'es gentil, tout le monde installe pas des serveurs web non plus.

Bof... le web n'est qu'une minuscule part de mon activité...

PK

--
      |      _,,,---,,_       Patrice KARATCHENTZEFF
ZZZzz /,`.-'`'    -.  ;-;;,_   mailto:p.karatchentzeff@free.fr
     |,4-  ) )-,_. , (  `'-'  http://p.karatchentzeff.free.fr
    '---''(_/--'  `-'_)       

Stephane TOUGARD <stephane@unices.org> wrote:

Patrice Karatchentzeff wrote:

Cela s'appelle l'égo : les gens sont persuadés de faire mieux donc on
ne réutilise pas ce qui a été fait. Un très gros classique en
informatique.

Si je peux me permettre de rajouter mon grain de sel, le défaut inverse,
qui consiste à connaître les outils d'une distribution et ne rien vouloir
savoir d'autre, ça fait des gros connards qui ne comprennent rien à rien
et ne veulent pas comprendre, et j'en connais. Je préfère de loin celui
qui revient à la base, même s'il réinvente la roue. Et je dirai que
cette tirade a une portée bien plus vaste que le simple problème des
distributions Linux.


--

Michel TALON

Kevin Denis <kevin@nowhere.invalid> wrote:

Au hasard, savoir que su -s /bin/sh est un debianisme qui ne fonctionne pas
au moins sur un systeme? (Bon, c'etait facile et tire par les cheveux.)

Je ne sais pas sous Debian, mais sous FreeBSD, la solution standard est
su -m toto
et apparemment c'est pareil sous Linux, selon la page man.

--

Michel TALON

On 24 Jul 2007 11:45:55 GMT, Stephane TOUGARD wrote:

C'est incroyable ca, un mec explique en un post les methodes de la
Slack, et la seule chose que l'autre Debian God trouve a repondre c'est
"on ne support pas Slack".

Mais qu'est ce qu'on en a a foutre de ce que tu supportes et de ce que
tu ne supportes pas ?

On m'a posé la question « as tu deja utilise une slack? », je réponds.
Si tu n'en as « rien à foutre », ne me lis pas, ou au moins, ne me
prends pas le chou parce que je réponds à une question qu'on me pose.

Excuse moi, j'ai toujours pas compris l'interet de booter en 20 secondes
plutot qu'en 30 ou en 40 secondes.

Pas grave, je n'attendais pas cela de toi.

Sam.
--
echo "creationism" | tr -d "holy godly goal"

Le 24-07-2007, Sam Hocevar <sam+news@zoy.org> a écrit :

/usr/doc/shadow-4.0.3/WISHLIST:- su -l, -m, -p, -s options (as in GNU su)
- done in the Debian patches

Euh, n'importe quoi. Ce ne sont absolument pas des patches dans GNU

su, c'est d'origine. Et c'est maintenant dans shadow su aussi, je ne
comprends pas trop pourquoi tu as la version 4.0.3 (sortie il y a plus
de 3 ans et demi) alors qu'il y a une release tous les trois mois.

Pourtant (et je suis alle reverifier sur un des sites de download):

http://ftp.lip6.fr/pub/linux/distributions/slackware/slackware-12.0/
slackware/a/shadow-4.0.3-i486-14.tgz
Oui, c'est sans doute vieux, je n'avais pas fait attention.
Maintenant, je n'ai fait qu'un grep, il faudrait lire en detail.

Pourtant, sur Google, 80 000 occurrences de var/lib/dpkg/info contre
18 000 occurrences de var/log/packages.

Quand on connait, oui. Mais j'ignorais meme que les paquets
avaient la liste des fichiers le composant dans un fichier plat.

Hum, je me demande bien dans quoi tu pensais que c'était stocké.

Tres honnetement? Je pensais que c'etait hache quelque part. J'ai

toujours ete surpris de la difference de vitesse entre rpm et dpkg.
J'imaginais que l'info etait interne a apt/dpkg et reserve a son
usage seul, donc hachee quelquepart. Ensuite, je ne crois pas avoir
trouve de docs qui en faisait mention (mais je fais confiance a
un quelqu'un passant par la pour me prouver que la doc existe).

On reprend dpkg? <snip>

Mais n'importe quoi. Je suis désolé mais soit tu mens délibérément,
soit tes informations sont vieilles de 10 ans, soit tu es de super
mauvaise foi.

Bon, je veux bien te faire confiance, mais ce probleme m'avait gravement

enquiquine pour plusieurs raisons et c'est a l'epoque la seule
solution qui m'avait ete donnee. Je suis retourne verifier dans un
man sur internet et j'avais vu la variable COLUMNS presente donc
je pensais que c'etait d'actualite.

Comme dit ailleurs, je vais reinstaller une debian, on verra. Ca
me permettra de troller sur des versions a jour.

Si je reprends slack, les paquets sont listables par un ls.

Sur Debian aussi : ls /var/lib/dpkg/info

Oui, tu l'as deja dit.

Si je veux
trouver le plus vieux paquet installe, je lis le man ls. Et plus
tard, dans ma vie d'admin, ca me servira.

Alors souviens-toi de |cat qui risque de te servir dans ta vie
d'admin...

yup, surement plus que la variable COLUMNS.

J'ai appris linux sur slack, j'ai bosse ensuite sur suze, redhat, debian
solaris et HPUX. Ce que j'ai appris sur debian m'a servi pour debian (et
fink sur mac OS X, mais c'est secondaire). Ce que j'ai appris sur
slack m'a servi partout, puisque j'ai appris a me servir de grep, tar,
awk, find, cut, etc, a lire des scripts shells, a chercher l'info etc..

C'est pas pour me moquer, mais si Slack t'a appris à chercher de
l'info vieille de plus de 7 ans

ou vois tu ca? De 3 ans et demi du paquetage shadow, ca passe a 7 ans?

à laquelle tu fais tellement confiance

je cherche l'info correspondante. Pour su, je regarde la doc. Si c'est
de la vieille doc moisie, ca correspond a la version de su que j'ai.
Donc il y a 3 ans et demi, la WISHLIST voulait le -s, apporte
par des patchs debian.

Maintenant oublions l'exemple su un instant et revenons a l'argumentaire
qui consiste a dire que debian t'apprend a te servir des outils
debian, alors que sur slack j'ai appris a me servir de linux (au
sens large, noyau, init, shell etc..).

A la question comment configurer le serveur de mail sous debian, on
repond
dpkg-reconfigure exim4
Ok. J'ai appris quoi, la? a me servir d'un serveur de mail, d'exim
ou de dpkg-configure?

Regarde les autres utilisateurs debian autour de ce thread:
-comment faire machin ou truc sur les paquets?
-dpkg, aptitude, apt-find, apt-get (personne n'a encore cite dselect?)

Tout ca, on peut l'avoir avec un simple ls ou un grep. Donc oui,
je ne nie pas que debian puisse arriver au resultat souhaite, mais
oui, c'est le bronx pour trouver le bon chemin. Et je continuerai
d'utiliser mes ls ou mes grep.

que tu l'utilises pour argumenter sur Usenet, il y a peut-être un
problème (le problème pouvant très bien être que j'accorde trop de
crédit à une argumentation sur Usenet, bien entendu).

nous trollons entre personnes de bonne volonte.

A l'opppose, seulement avec ce que je t'ai dit plus haut, tu devrais
etre capable de te debrouiller sur slack.

Bof, non. Ça ne me dit pas comment je bootstrape un chroot de Slack,

j'utilise des qemu pour mes tests, mais je pense que qemu ne te conviendra
pas. Ensuite precise ce que tu veux faire, je doute que ce soit
impossible (c'est eventuellement complique).

comment je sais si je dois recompiler mes programmes après avoir mis à
jour une bibliothèque,

quelle difference avec debian/redhat/whatever? Je compile mon
programme prog.c qui appelle la libtoto. Le systeme met toto a
jour. Comment savoir si prog fonctionne encore?

comment désactiver le serveur web en runlevel 4,

cette notion n'existe pas vraiment sous slack. Et comme dit plus haut,
le rc.M appelle:
if [ -x /etc/rc.d/rc.httpd ]
. /etc/rc.d/rc.httpd
fi
donc, au choix un mv /etc/rc.d/rc.httpd /etc/rc.d/rc.httpd-OFF ou
chmod -x /etc/rc.d/rc.httpd Pour desactiver apache en runlevel
2, 3, 4 et 5.

comment passer de inetd à xinetd sans récrire ma config,

pas de xinetd sous slack. Je suppose qu'il existe des scripts de
conversion sous debian permettant de passer en douceur de l'un a l'autre?
sous slack, il n'y a pas. Tu devras reecrire ta config, c'est a dire
lire de la doc de _xinetd_. Et non pas croiser les doigts en esperant que
ca passe, voir que ca plante, tenter de comprendre le script qui a
ete fait, voir si on peut rattraper le coup avec le script ou tout
reprendre a la main, etc etc..

et comment avoir une Slack avec des softs à jour.

wget http://ftp.lip6.fr/pub/linux/distributions/slackware/slackware-12.0-iso/
slackware-12.0-install-d1.iso

Parce que shadow 4.0.3 dans la
Slack 12.0 sortie il y a 3 semaines, pardon encore, mais je rigole bien.

Effectivement. J'en suis le premier surpris.

Pour les paquets, je pensais utiliser la gestion des paquets. Si je
reinstalle une librairie de cette maniere, comment va se comporter
le gestionnaire de paquet? Va t'il fonctionner ensuite?

Tu me fais penser à Eric S. Raymond qui vilipende Fedora parce que
"it's possible to inadvertently remove a shared library [...] and be
unrecoverably screwed". J'ai un scoop pour toi : quand tu fais une
connerie, que ce soit virer ta libc

Non. J'ai egalement un scoop pour toi. Il y a des conneries reparables
et d'autres irreparables. La perte de la libc entre dans quelle
categorie?
Je t'ai donne la methode pour faire repartir une slack apres
suppression de sa glibc. La slack tourne encore. Cela veut il dire
que ta methode est seulement capable de faire repartir boiteusement
la debian? Et apres ca t'etonne que slackware est dite rock-solid
et que des generations d'user ont piteusement demoli leur debian?

Si tu fais des conneries

le probleme c'est qu'il faut recuperer quelquefois les conneries des
autres. Donc oui, je prefere quelquefois etudier certains cas critiques
pour connaitre des procedures afin de repartir. La suppression d'une
libc est un bon exercice. La debian n'est donc pas libc-recover-proof.
Slack l'est. Je n'ai pas essaye les autres.

--
Kevin