Reprise du message précédent :
ca va être foireux, parce que systemd est dans arch, et peut pas se porter sur bsd ...

Bah. ils tourneront avec les initscripts à l'ancienne  

Allan McRae explique bien sur son blog pourquoi cette option n'est pas vraiment tenable (sauf à se passer de udev sur le long terme)

D'ailleurs ca va être intéressant de voir si la team BSD essaye de porter des composants pour remplacer systemd, de la meme façon qu'elle a bossé sur llvm/clang pour remplacer gcc.
De toutes façons ces écosystèmes tirent dans des directions opposées, les softs linux glissent tendanciellement vers la GPLv3, alors que bcp de devs sortent leur code en MIT/BSD

edit : visiblement ils partent sur un portage des scripts gentoo et openrc

https://bbs.archlinux.org/viewtopic [...] =89001&p=4

Rho les copieurs
 
http://www.generation-nt.com/ubunt [...] 85232.html

en gros du debian sid "unstable" rebadgé ubuntu ?

pas sûr que ça tienne le coup vu le boulot de surveillance des sorties release de chaque paquet, puis de correction/rétro-pédalage en cas d'instabilité/bug, ils vont devenir fous les développeurs ubuntu

Après le dérivé d'Arch avec le noyau de (Free)BSD, voici celui qui se prends pour une OpenBSD avec un noyau linux : http://starchlinux.org/

openbsd je voit pas trop l'intéret sur le kernel, mais par contre musl ca poutre

sta.li fait ca avec un kernel linux

Tiens ils essaient de reprendre la tres bonne idée de stali, tout linké statiquement !

c'est bien, oui et non
 
- augmente le besoin de mémoire
- en cas de problème dans une lib, faut tout relinker, on peut pas juste patcher la lib.

Attention, nouvelle maj de glibc et il faut faire gaffe avec les symlinks.
 
Attention aussi aux paquets AUR sur amd64
 
https://www.archlinux.org/news/upda [...] -together/
 

rien remarqué d'anormal chez moi quand j'ai tapé "pacman -Syu", j'ai pas vu de paquet glibc ou de filesystem-2013.01-1 :
 

 
peut-être que le miroir mir.archlinux n'a pas encore ces 2 paquets à jour

La mise a jour a ete transparente ici.

 
Mise à jour de ma VM VirtualBox en Testing aussi avec filesystem 2013.1-1 et glibc 2.17-3 mais bon comme je suis en i686 sur celle-ci, je ne risquais normalement pas grand chose.
 
D'ailleurs la -3 apporte juste un check de filesystem, le diff entre la -2 et -3
 

il me restait qques bricoles inutiles dans /usr/lib64 (des dossiers vides d'anciens paquet).
 
/usr/lib64 supprimé et la màj du paquet filesystem s'est faite.

 
depuis la mailing list

 
Mon pacman est configuré pour mettre à jour glibc en premier. Je pensais que ça passait mais ça m'a explosé mon arch. J'ai mis à jour glibc tout seul, ensuite plus rien ne se lançait. Je tape pacman, ça me met "/usr/bin/pacam not found". Ca me met ça même si je lance le chemin complet avec l'autocompletion.
 
Du coup ça ne boot plus, je ne peux que lance windows....
 
Vous savez si la nouvelle iso d'install me permettrait de mettre à jour le filesystem et de récupérer tout ça ??

 
Toutes les ISO servent aussi de rescue, donc ça devrait passer, il faut juste mater le Wiki.

Sinon, un petit liveUSB + chroot, ça devrait fonctionner, non ?

 
pourquoi avoir configuré de cette manière ?
 
la news indiquait pourtant bien qu'il fallait que glibc et filesystem soient mis à jour ensemble lors d'un même et unique "pacman -Syu",
 
le seul paquet que j'ai contraint à mettre à jour en premier c'est le paquet "archlinux-keyring" pour éviter d'avoir le bug du paquet qui a une signature trop récente par rapport à la version de archlinux-keyring

 
J'avais glibc en syncfirst pour les même raisons que tu as archlinux-keyring. J'en ai eu besoin une fois pour que l'upgrade passe et je l'ai gardé.
 
Bon en tout cas j'ai pas tout compris, j'ai lancé le live-usb, bataillé avec les modules pour monter l'interface réseau. Ensuite j'ai juste monté la partition système en /mnt et tapé "pacstrap /mnt filesystemd" et c'est passé. J'avais plus qu'à redémarrer    

ah tien, je ne connaissais pas cette commande ! (pacstrap)

/me va se documenter !

EDIT : ok, c'est en fait une commande pour faire des install à partir d'une ISO d'arch... Je n'avais pas suivi cette actu... pratique !

n'empêche qu'on peut se demander s'il y aurait pas un moyen ici d'améliorer le logiciel pacman pour éviter de casser son système vis à vis de glibc et de filesystem  

logiquement on pourrait se dire que lorsqu'on fait un "pacman -Syu" pacman devrait en parallèle vérifier que la mise à jour qu'il est en train de faire n'est pas en train de casser le système, dans l'idéal pacman devrait être configuré pour ne jamais casser le système lors d'une mise à jour des paquets, qu'on puisse casser un système en désinstallant comme un barbare des paquets essentiels je peux le comprendre, mais il n'est pas normal de casser son système quand on fait un simple "pacman -Syu" ( mise à jour générale des paquets ),

ça nécessiterait une nouvelle fonctionnalité pour pacman qui n'est pas forcément compliquée à programmer, par exemple quand il télécharge les fichiers index de la liste des paquets ( dépots core, community, extra ) il pourrait aussi télécharger une liste des scénarios aboutissant à une casse du système ( le cas glibc et filesystem non mis à jour ensemble ), ce qui permettrait à pacman de vérifier si les conditions du "crash" vont se produire, si c'est le cas il émettrait un warning pour avertir l'utilisateur qu'il est en train de faire une grosse connerie ( "voulez-vous continuer ? ( o/N )" ),

en gros un pacman avec un peu d'intelligence artificielle

pour l'instant l'intelligence artificielle de pacman elle se limite à des infos de type "ce paquet peut avoir besoin de dépendances supplémentaires : liste des dépendances optionnelles" ou à des vérifications de dépendance quand on désinstalle un paquet, les conflits de version, mais il est incapable de détecter les crashs potentiels dus à un non respect des news de mise à jour

Il y a trop de conditions initiales différentes alors qu'en rolling release ça ne devrait pas être le cas, mais tout le monde ne met pas à jour à la même fréquence, donc pour maintenir cette idée de scénarii, bon courage. D'ailleurs, je ne pense pas qu'avoir un paramètre SyncFirst custom dans le pacman.conf arrange les choses.
 
Je suis en Testing sur certaines de mes machines, que l'upgrade soit parfois foireuse (pas de souvenir récent de ça du reste), ça me choque pas plus que ça, l'erreur est humaine, mais par contre que sur la release "out-of-the-box", on en arrive à des blocages, je peux comprendre que ça énerve, sauf que pour le moment je ne vois pas de post sur le forum allant dans le sens d'un gros problème avec filesystem suite au pacman -Syu.

 
en même temps il n'y a pas 50000 scénarios possibles qui aboutissent à un crash système, tu regardes l'historique des news à problème sur le site d'archlinux ça doit pas dépasser la dizaine sur un an  

 
D'autant plus que la news a été postée *avant* l'update.
 
peut être qu'il faut que pacman affiche les news de maj *avant* de proposer de télécharger les paquets

Elbarto : il suffit que glibc EXIGE la version minimale adéquate de systemd (DEPENDS=... je crois), et tu auras au moins un warning, voire un blocage ! (pas testé, mais ça doit se passer comme ça).
Non ? je me trompe ?
Si j'ai raison, il faudrait simplement que le SyncFirst soit automatiquement désactivé pour ce genre de cas (avec un warning, c'est toujours mieux !).

oui ce serait déjà une avancée, une option dans le fichier de configuration "display_critical_news_before_update = true"

l'idée c'est toujours d'éviter de casser bêtement son système juste parce qu'on a zappé involontairement une news ou qu'elle a été mal interprétée

encore une fois, être inscrit à la mailing list dev-public c'est l'assurance de pas manquer ce genre de chose

 
oui peut-être,
 
à vrai dire quand j'ai lu la news concernant glibc et filesystem j'ai pas vraiment compris cette notion de "update together", dans la mesure où un paquet peut exiger l'installation d'une version précise d'un autre paquet alors le fait d'installer séparément glibc ( pacman -S glibc ) devrait automatiquement installer en même temps la nouvelle version de filesystem  

 
encore faut-il penser à vérifier à chaque fois les nouveaux messages de la mailing list et de faire le tri
 
du coup tu risques de passer à travers l'info,
 
alors qu'un affichage direct des news délicates dans pacman là t'es sûr de ne pas la louper

 
Ça par contre, je trouve le truc intéressant, me semble que gentoo fait un truc du genre pour les MàJ un peu chaudes. Pour l'histoire de la ML, je veux bien, mais justement https://mailman.archlinux.org/piper [...] hread.html n'est pas une ML récapitulative comme pourrait l'être https://mailman.archlinux.org/piper [...] hread.html qui du coup suffit (normalement).

 
Ouai, au lieu de vouloir réinventer des trucs, finalement ça n'est pas une simple dépendance ? Glibc exige filesystem > version XX et réciproquement ?
 
Après dans mon cas je ne rejette la faute sur personne, j'ai lancé le truc à l'arrache et je n'avais pas prévu que ça pourrait faire ça. Du coup j'ai viré glibc de syncfirst, je n'ai plus que pacman et yaourt je crois.

et encore, pacman et yaourt, c'est pas primordial en SyncFirst... (ou alors faut m'expliquer ).

Ca doit dater de http://archlinux.fr/news/sortie-de-pacman-3-5-0 mais finalement ça semble déconseillé et/ou inutile ...

 
Dans le fichier de conf d'origine, il y a pacman en Firstsync.

https://www.archlinux.org/news/fina [...] n-warning/
 
initscripts retirés des dépots

mais on peut trouver ça dans le dépot aur :
 
https://aur.archlinux.org/packages/initscripts-fork/
 
edit: magicpanda --> où est passé ton avatar obama ?

J'ai changé pour suivre l'actu, c'est bon Obama a été ré élu

KDE 4.10 viens de debarquer, ainsi que steam !
 
J'avais installe steam via AUR. Il a detecte tout seul que c'est le meme package. J'ai rien de special a faire avec du coup ?

j'ai des soucis de mise à jour aujourd'hui :
 

 
c'est apparu après avoir répondu oui à cette question :
 

 
que faire ?

Moi je serais ben capable de faire rm des fichiers en question