> > Pour finir, Mandrake 10.1, Suse 9.2 et Debian utilisent /etc/init.d/hotplug au boot!
Pas Mandrake 10.1 !!!!!!!!!!!!!!!!!!!!!!!!
Je n'ai pas vu ça pour Mandrake 10.1 rc1.
Ce n'est pas activé par le paquet hotplug (il y a /etc/rc.d/init.d/hotplug):
$ rpm -q --scripts -p hotplug-2004_04_01-8mdk.i586.rpm
preinstall scriptlet (using /bin/sh):
if [ ! -L /usr/lib/hotplug ]; then
echo "Moving /usr/lib/hotplug to /lib/hotplug"
mkdir -p /lib/hotplug/
mv /usr/lib/hotplug/* /lib/hotplug/
rmdir /usr/lib/hotplug
cd /usr/lib/
ln -s ../../lib/hotplug hotplug
fi
postinstall scriptlet (using /bin/sh):
/usr/sbin/update-usb.usermap || :
Je ne vois pas de "chkconfig --add" ou "add-service".
Et pour SuSE 9.2, manifestement je ferais mieux de regarder moi même....
> Donc en clair, toutes les distrib utilisent modules.usbmap sauf RedHat...
PPsssssssssssssssssssss.
Cette obsession de la conspiration Red Hat... Red Hat pourri le libre, Red Hat le microsoft du libre, etc...
T'as prelink sur ta bécane ?
C'est Red Hat qui l'a fait.
T'as ext3 sur ta bécane ?
C'est Red Hat qui bosse le plus sur ext3 (c'est pas le seul)
T'as gamin (remplaçant de fam) ?
C'est Red Hat.
T'as nptl ?
C'est Red Hat.
T'as gcc ?
Red Hat fait 20 % minimum du boulot sur gcc.
T'as la libc ? oui forcément.
C'est Red Hat qui fait 40 % du boulot.
Nautilus ?
Le mainteneur est Red Hat.
Gtk+ ?
Le mainteneur est Red Hat.
Nash utilisé par Mandrake, c'est Red Hat.
Dbus ?
Red Hat en a fait une bonne partie.
PAM ?
Red Hat y a beaucoup bossé aussi.
Xorg ?
Red Hat a poussé pour son émergeance. Introduit au milieu du beta cycle de FC2.
etc...
Si Red Hat n'utilise pas /lib/modules/.../modules.usbmap, c'est leur affaire. Ça les regarde. On peut dire qu'ils ont tords. Mais les "sauf Red Hat..." et autre "RedHat/Fedora est maintenant une distribution à part, non standard et donc à éviter" sont au mieux tout simplement cons.
Red Hat n'a pas à être aux ordres de Debian ou attendre de Debian un accord pour faire quelque chose ! C'est claire ?
btw, Red Hat utilise modules.usbmap. modules.usbmap est généré par depmod avec les infos dans les modules.
> Pourrait tu nous eclairer sur ce qu'il se passe sous fedora alors?
Bonne question. J'ai donné une tendance de fond. Il semble (ce n'est pas facile à deviner car il y a une évolution rapide) que hotplug (userland) ne sera là "que" pour communiquer certains evènements noyau. Le chargement de module supplémentaire se fait/fera automatiquement. Chargement à la demande "classique" sera fait dans la grande majorité des cas. Udev soulève quelque problème et peut-être qu'a côté de ioctl("/dev/...") il y aura aussi ioctl((major, mineur)). C'est à hal (par exemple) avec les informations dans "/sys" et/ou "/proc" de monter la clée usb (le module sera automatiquement chargé à ce moment). Le nouveau module-init-tools a aussi un rôle central tout comme "/sys".
"/etc/dev.d" (utilisé par udev _après_ l'installation du modules et _après_ la création des fichiers spéciaux) sera utilisé pour configurer le matériel (restaurer le son, charger un firmware, par exemple).
Ceci dit, pour usb, je n'en sais pas beaucoup car je n'ai pas usb.
Pour FC3, tout (ou presque) est absolument standard de ce côté (sinon regarde les patchs dans les paquets). Dans un premier temps, Fedora ne voulait pas de udev dans FC3 (on l'a tous remarqué, il y a quelques problèmes pour le chargement à la demande). Le mainteneur de udev est venu défendre l'intérêt de udev sur la mailing Fedora. Un employé Red Hat a aussi défendu udev avec l'argument "massu" qu'il était facile de gérer 2000 disque dur avec (cas des gros serveurs). Finalement udev a trouvé son chemin sur le tard. Red Hat a _beaucoup_ bossé sur hal (en upstream) durant la phase de test de FC3.
Amuses toi à installer une FC3T1 puis une FC3 finale (toute proche) pour voir l'énorme différence et l'énorme boulot. FC3 finale aura les dernières version de udev (039) et hal (0.4.0). Sans travailler "main dans la main" avec les développeurs en upstream, ce n'est pas possible.
3. Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages.
5. Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades.
Non-Objectives of Fedora Core:
3. Being a dumping ground for unmaintained or poorly designed software.
[^] # Re: Drôle de surprise !
Posté par 007 . En réponse à la dépêche Sortie de la Debian Woody 3.0r3. Évalué à 1.
Pas Mandrake 10.1 !!!!!!!!!!!!!!!!!!!!!!!!
Je n'ai pas vu ça pour Mandrake 10.1 rc1.
Ce n'est pas activé par le paquet hotplug (il y a /etc/rc.d/init.d/hotplug):
$ rpm -q --scripts -p hotplug-2004_04_01-8mdk.i586.rpm
preinstall scriptlet (using /bin/sh):
if [ ! -L /usr/lib/hotplug ]; then
echo "Moving /usr/lib/hotplug to /lib/hotplug"
mkdir -p /lib/hotplug/
mv /usr/lib/hotplug/* /lib/hotplug/
rmdir /usr/lib/hotplug
cd /usr/lib/
ln -s ../../lib/hotplug hotplug
fi
postinstall scriptlet (using /bin/sh):
/usr/sbin/update-usb.usermap || :
Je ne vois pas de "chkconfig --add" ou "add-service".
Et pour SuSE 9.2, manifestement je ferais mieux de regarder moi même....
> Donc en clair, toutes les distrib utilisent modules.usbmap sauf RedHat...
PPsssssssssssssssssssss.
Cette obsession de la conspiration Red Hat... Red Hat pourri le libre, Red Hat le microsoft du libre, etc...
T'as prelink sur ta bécane ?
C'est Red Hat qui l'a fait.
T'as ext3 sur ta bécane ?
C'est Red Hat qui bosse le plus sur ext3 (c'est pas le seul)
T'as gamin (remplaçant de fam) ?
C'est Red Hat.
T'as nptl ?
C'est Red Hat.
T'as gcc ?
Red Hat fait 20 % minimum du boulot sur gcc.
T'as la libc ? oui forcément.
C'est Red Hat qui fait 40 % du boulot.
Nautilus ?
Le mainteneur est Red Hat.
Gtk+ ?
Le mainteneur est Red Hat.
Nash utilisé par Mandrake, c'est Red Hat.
Dbus ?
Red Hat en a fait une bonne partie.
PAM ?
Red Hat y a beaucoup bossé aussi.
Xorg ?
Red Hat a poussé pour son émergeance. Introduit au milieu du beta cycle de FC2.
etc...
Si Red Hat n'utilise pas /lib/modules/.../modules.usbmap, c'est leur affaire. Ça les regarde. On peut dire qu'ils ont tords. Mais les "sauf Red Hat..." et autre "RedHat/Fedora est maintenant une distribution à part, non standard et donc à éviter" sont au mieux tout simplement cons.
Red Hat n'a pas à être aux ordres de Debian ou attendre de Debian un accord pour faire quelque chose ! C'est claire ?
btw, Red Hat utilise modules.usbmap. modules.usbmap est généré par depmod avec les infos dans les modules.
> Pourrait tu nous eclairer sur ce qu'il se passe sous fedora alors?
Bonne question. J'ai donné une tendance de fond. Il semble (ce n'est pas facile à deviner car il y a une évolution rapide) que hotplug (userland) ne sera là "que" pour communiquer certains evènements noyau. Le chargement de module supplémentaire se fait/fera automatiquement. Chargement à la demande "classique" sera fait dans la grande majorité des cas. Udev soulève quelque problème et peut-être qu'a côté de ioctl("/dev/...") il y aura aussi ioctl((major, mineur)). C'est à hal (par exemple) avec les informations dans "/sys" et/ou "/proc" de monter la clée usb (le module sera automatiquement chargé à ce moment). Le nouveau module-init-tools a aussi un rôle central tout comme "/sys".
"/etc/dev.d" (utilisé par udev _après_ l'installation du modules et _après_ la création des fichiers spéciaux) sera utilisé pour configurer le matériel (restaurer le son, charger un firmware, par exemple).
Ceci dit, pour usb, je n'en sais pas beaucoup car je n'ai pas usb.
Pour FC3, tout (ou presque) est absolument standard de ce côté (sinon regarde les patchs dans les paquets). Dans un premier temps, Fedora ne voulait pas de udev dans FC3 (on l'a tous remarqué, il y a quelques problèmes pour le chargement à la demande). Le mainteneur de udev est venu défendre l'intérêt de udev sur la mailing Fedora. Un employé Red Hat a aussi défendu udev avec l'argument "massu" qu'il était facile de gérer 2000 disque dur avec (cas des gros serveurs). Finalement udev a trouvé son chemin sur le tard. Red Hat a _beaucoup_ bossé sur hal (en upstream) durant la phase de test de FC3.
Amuses toi à installer une FC3T1 puis une FC3 finale (toute proche) pour voir l'énorme différence et l'énorme boulot. FC3 finale aura les dernières version de udev (039) et hal (0.4.0). Sans travailler "main dans la main" avec les développeurs en upstream, ce n'est pas possible.
Pour finir : http://fedora.redhat.com/about/objectives.html(...)
3. Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages.
5. Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades.
Non-Objectives of Fedora Core:
3. Being a dumping ground for unmaintained or poorly designed software.
Globalement c'est le cas.