Arch Linux 16
■ このスレッドは過去ログ倉庫に格納されています
そりゃ会話の流れ的に、開発用途で入れたライブラリで
Xmonadの方のHaskellの依存が壊れたんでしょ 開発でHaskellライブラリ使うことあるのか
猛者かね
もう4〜5年近くarch使ってるけど、公式アナウンスされるのとほんの少し程度しか依存関係然りbootしなくなったことねーけどな〜
皆猛者で弄りまくってるからなのか、皆が何も考えず弄ってるのか、はたまた俺が優秀なのか、はたまた俺がなんも弄らんで使ってるから壊れないのか
どれなんだ一体？！ Archでマイナーな構成にすると
自分しか遭遇しないであろうトラブルにも結構見舞われるから
もう諦めてGNOMEにしてるわ 実際ソフトウェア開発にはあまり向いてないね
公式の開発環境の導入手順がDebianやfedora用しか紹介されてない事が多いし 開発とかいう言葉に逃げてるフシがあるが、本当に開発のために夥しい数のかつdevelopingなパッケージをインストールする必要があるなら今はdocker等を検討するべきでしょう
それに、DebianやFedoraは平気なのにpacmanでは解決できてない依存関係というのが本当に存在するなら、抽象的な物言いでなく具体的にいつのどれと言えば良い
>>613とは別人だと思うが、
> 自分の開発環境とディストリの配布物は混ぜない
って何を今更ってくらい当たり前のことですよ
アマチュア開発者さんたちの率先してわけわからんことして喜ぶくせ、本当に良くないよ ArchはAURで勝手に開発用の依存関係入れてくるから
AURが必要ないようなミニマルな用途じゃない限りは避けられないでしょう
逆に619さんがどういう用途でArchを使っているのか気になるよ 一言に開発と言っても言語やフレームワークによって前提条件異なるからそこの認識合わせないと議論はすれ違い続けるのでは それ 情報系言葉の定義が広かったり、多様な意味あったりとで明確な名称で定着してほしいもんだ >>620
それが、Archが公式にAURパッケージのインストール補助をしない理由なんですよ
> ArchはAURで勝手に開発用の依存関係入れてくるから
これは言っちゃ悪いが糖質並みの妄言だ
いつどのように「ArchがAURで勝手に開発用の依存関係入れ」たのか説明しろ
逃げんなよ絶対しろ node.jsだったらnvm使うしrubyだったらrvm使う
それがhaskellだったらstackだったってだけでは 全部過去の話よ
https://wiki.archlinux.org/index.php?title=Haskell&;oldid=294693 あたりの
日々使うソフトはpacmanで管理したいけど、ちょっと興味が湧くから開発環境も入れるじゃん？
cabal-installとかもとりあえず使ってみるじゃん？
で、しばらくするとcabal-installで入れたもの、それを元にmakepkgしたhaskellのパッケージ、pacmanが管理しているもの
全部が混在することになってpacman -Syuするとghc-pkgが怒る
もちろん、これは「何もしていないのに壊れた」なんて当時も思っちゃいなかったが、「何が悪いのか分からない」状態にはなった。 言語やフレームワークごとにパッケージマネージャがある場合はどう考えてもディストリのパッケージマネージャとは使い分けるべきだ
pip しかり cabal しかり
使い分けると言っても、単にユーザー環境下 ($HOME 以下) にインストールすることにすれば足る話
これは開発とはまたレイヤの違う、常識やモラルの話だろう
>>625さんは分かっておいでのことだと思うが、他の多くの方はどうもこの点を理解されていない やっぱ結局なーんも理解しないで｢何もしてないのにぶっ壊れた｣って騒いでるだけっていうね "ぎじゅつりょく"至上主義は頂けないな。
発展性の無い事に頭や時間を使うのは趣味でしか無い事くらい自覚しときなよ。 ライブラリを共有するのが悪いってことでそれがsnap？ 話のきっかけの<<605たけど、
俺は一言も開発環境と言ってなくて、haskellの公式パッケージはたびたび依存関係が壊れるって話。
Rubyもnodejsもシステムのパッケージ壊れないだろ。
ちなみにたまーにglibが壊れるのと同じ理由、原理的に壊れないということはないのよ。
バイナリ配布は難しいのよ。 いつんなったら自分がサポート外のことしてぶっ壊してるだけなんだって気づくんだろ 相変わらず｢壊れた｣が何を意味してんのかすらはっきり言わねぇからあれだけど
仕組み的にはサポート外のことしなきゃ壊れなくなってるしサポート外のことしてないのに壊れてるならバグレポすればいいだけ
ちゃんと理解してるなら対応も簡単だし今ここでバージョンとかの具体例を上げればいいだけ
理解して無くて｢なんもしてないのに壊れたよふぇぇぇ｣とかしか出来ないから具体例が上げられないんだよな ちょっとまって、依存関係が壊れた で何を意味してるかわからないユーザーがいるの？
シングルバイナリじゃないとモジュールに依存して動くんだけど、それが壊れるってだけなんだけど、それがわからないの？？ >>633
どんだけレベル低いんだよ
ただ｢壊れる｣としか言わねぇんじゃ動的リンク時の話なのかもロード時の話なのか単純にライブラリが見つからないのかとかsonameの付け間違いなのかそれらが上流のバグなのかArchのバグなのかアホユーザーが自分で壊したせいなのかとか腐るほど可能性があって話にならねぇんだよ
だからバージョンなりエラーなり具体的に言えっつってんの >>634
なんていうか、おつかれ。俺そんなのはコミュニティに直接報告するからここでは書いても意味ないし、知りたいことは自分で調べるから十分だわ。
説明してマンに説明するぐらいなら開発者に言うわ。
あと大抵、pkgbuildのミスかパッケージ更新のタイミングが殆どの原因だよ。
Haskellはバージョンが変わると基本全部ビルドし直しだから更新のタイミングがずれただけで壊れる。
これ以上は説明する気さえ起きない。調べろ。 あと普通はリンクできなくてエラーになるのを依存関係が壊れると言うと思う。
言葉ミスってる奴はいるし、俺はスルーしてる。
他の原因まで考えないそれが普通。
間違ってたら間違ってるよといえばいいだけ。
ロードできないとかは依存関係は壊れてないだろ。 勝手に可能性を広げて拡大解釈して意味わからんとか何がしたいか全然わからん。 な、結局なーんも理解しないで自分でぶっ壊して｢なんにもしてないのに壊れた！｣とか言ってるだけだろ？ >>638
ちゃんと読めよ。遠回しに否定されてんだろ > あと普通はリンクできなくてエラーになるのを依存関係が壊れると言うと思う。
な、やっぱなーんも理解してない
リンク時にエラーになるっつーのはつまり自分でビルドしてるときの話なわけだがそれはつまり公式の立場から見りゃAURと同じで"サポート外"なわけ
公式のパッケージは依存するライブラリの非互換な変更によるリビルドやパッチの必要性をTODOでリスト化して対応してから一斉にアプデって形がとれるけど
無限にあるユーザーのオレオレビルドオレオレパッチのために公式の側のアプデを遅らせるなんて不可能だからな
んでそれは固定リリースのUbuntuだろうがDebianだろうがリリースが変われば非互換な変更が起きるんで同様の問題が起きる事に変わりはない >>630
golangやrustといった最近の言語が静的リンクデフォルトにしてるのはバイナリ配布難しい問題に対する一つの回答なのかね
言語のランタイムも静的リンクするからコンパイラのバージョンアップでABI/APIが変わっても影響されない
その分ディスク容量は食うわけで富豪的な解決策ではあるが >>642
*nixのモジュール主義は初期のディスク容量の制限からきてるし、当初はみんなビルドしてたから問題なかったし、動的リンクの方が良かった。
今は静的リンクの方がめんどくさくないから当然考えられるオプションだと思うよ。
なるべく依存したくないのはみんな同じだと思う。 >>641
当然、自分でビルドしてないのに見つからないことがあります。
他人には詳細に前後の関係を求めるくせに、自分は偏見で判断するの良くないよ。
あと依存が壊れたのをアーチの所為には誰もしてない。壊れたと事実を言ってるだけ。 Ubuntuなら壊れないとかDebianならこんな事にはならないなんて誰も言ってないのにそういう声が聞こえるみたいだし、なんかの病気だろうね まあでもHaskellの依存関係が壊れるのは頻繁にHaskellのバージョンを上げてるのが一番の原因だけどな。
関連パッケージが同時に更新されないのも痛い。
Haskellに関してはアーチとの相性が圧倒的に悪い。
あと単純にHaskellが時代遅れ。
xmonad使う層が自分たちで解決しちゃうのもあって初見殺し感もある haskellはビルドした時点で依存関係がガチガチに固まるってことを分かってない人がいるな
今は1000近いhaskellのパッケージをほぼ1人で作成しているんで壊れにくくなってる
が、これってあんま健全じゃない >>606ゥ？？？
> 昔からフルビルドして使ってる人からしたらパッケージマネージャーは依存関係の補助でしかなくて、Linuxにインストールするソフトやファイルの位置は自分でコントロールするのが普通でpacmanはそれがやりやすいだけで、依存関係をわざと壊そうとしたら普通に壊せるからな。
頓珍漢もいいとこだぞ
サポート外のことしか書いてない 少なくともID:kIV0YRftがサポート外のことして「壊し」てるのは確定ですね
>>635辺り見てもAURを公式と見なしてるの確定
ID違うが>>620と同じ奴か？
こんだけ言われててなおこんなに基本的なこと分かってない奴が何人もいるって思いたくないのだが 話変わる質問なんだけど、
言語由来のパッケージマネージャーであるpip然りでインストールするより、aurなり公式リポジトリからインストールすべきなの？それとも言語由来のパッケージマネージャーで入れるべき? 誰かHaskellの関連パッケージがAURじゃなくて公式のパッケージって教えてやれよ >>651
使いたいのがシステム側で使うだけのツールならそれも含めて公式から入れてもいいけどバージョン指定したり最新が良い、公式に無いパッケージも使う開発用なら環境丸ごと仮想化したほうが楽 誰か公式パッケージで起きるならバグだからレポートしろで終わりって教えてやれよ >>651
好みもあるだろうから一概に言えんが、pacmanで入れるpythonはシステムだからAURでもいい、ただし、ちゃんと管理、更新して。ホームディレクトリで管理する開発用のpythonはpipにすればいい。ユーザーで環境変わるので。 Haskellの公式の依存関係壊れるって話は、バグじゃないんだよ。
ビルドが落ちてくるタイミングで違うんだ。リポジトリのサーバーの更新のタイミングのせい。
構造的な問題って話。
こればっかりはアーチとHaskellの更新スピードとビルドの相性が悪いの。
だからみんなHaskellはアーチのビルド使わずにstack使うわって話したわけ。
なんにも知らないのに依存関係ポリスが突っ込んでくんな。検索ノイズ増えるからやめろ。 repo-addがロックファイル作ってatomicに更新されるんだからんなこと起こるわけねぇだろ
そんなタイミング依存の競合状態すら考慮してないとか開発者舐めんのもいい加減にしろボケ 1000のパッケージがバージョンアップごとにビルドが必要でって件理解してないのかこいつ 1000件ありゃタイミング依存の競合状態が許容されるとでも？
件数の問題じゃねぇんだよ
お前が言ってる状態がもし許容されるならそれはタイミングによって極わずかでも任意のコード実行とかの脆弱性に繋がりうるから許されるようなもんじゃねぇの
マジでちゃんと考えてる開発者に足りない脳みそで適当こいてションベン引掛けんじゃねぇよクソが HaskellのArchwiki読んでこいよ。わざわざシステム用に動的リンクでビルドしてるんだぞ。意味わかってんのか? 下品なコメント以外は有意義のレスついたし、俺は無料で教育するのまっぴらだしこの辺で。 使えないやつほどわかってるつもりの発言するし態度が悪いから掲示板上で教えるのは難しいんだよね >>651
>>626
依存関係を解決する目的で pacman がインストールするものについては、pacman の好きなようにさせてやれば良いと思う
ユーザーが自分の目的でたとえば pip install するパッケージは、仮想化とは言わないまでも、$HOME 以下にインストールするべきでしょう
すなわち sudo pip install なんて普通はするべきじゃない AUR に置いてあるパッケージは、言語のパッケージマネージャがあるなら、使うメリットないように思える >>662
どのレスを有意義なものと見なしてるの？笑 Pythonのパッケージなんかはインストールにクセあったりする場合あるしAURにほとんど揃ってるからAURで揃えるの全然ありだな
エコシステムがちゃんと自分のとこで解決してるRustなんかは逆にほとんどAURにライブラリ上がってないし
Haskellは特殊だからArchWikiに記事作られてるんかね AURのパッケージが
別のAURのパッケージを引っ張って依存関係を解決できる仕様になってるから消せないんだろう
直接叩かなくても他のAURから勝手に使われる >>667
> Pythonのパッケージなんかはインストールにクセあったりする場合ある
どういうの？ >>669
PyPIから素直に入れられないパッケージ、具体的にはDL関係が特に自分的に辛い ID:kIV0YRft = ID:jI2iSlEc でしょ？
>>606に安価飛ばして何か言ってる気になってる時点で終わりです
引っ込みつかなくなって暴れてるだけでしょう 言語系はdockerとかで隔離してvscode remoteとかで動かすと環境汚れなくていいよgui系は無理だけど docker使ったことがあればコンテナ内のアプリでは〜ってわかるやろ。 配布用のバイナリ作るときは最近はdockerじゃなかったけ？ amdgpuのロードがちょいちょいされなくなる？何が原因だろう fedoraチームがシステム側をコンテナ化する逆転の発想ディストリを実験中だから
Linuxの環境問題も数年後には改善されそう フォントはホームディレクトリの.fonts内に置いても認識されるから
他ディストリから引っ張るならホームディレクトリに置く方法で試した方がいいと思う。
この方法ならArchの再構築した時でもホームさえ使い回せばフォントも維持されてかなり楽。 買収したCoreOSとOS Tree の悪魔合体じゃないの。ChromeOS関係無いでしょ。 Fedoraの不安定さって、更新で依存関係が壊れるとかじゃなくて
wayland採用でアプリが動かないとか、pipewire採用で音が鳴らないみたいな根本的な部分での不安定さだから
コンテナ化されても大して意味がなさそう chromeOSは2つのシステムをパーティションで分けてインストールするからアップデートに失敗がないのよな
fedoraのOSTreeは1つのパーティションでスイッチしてシステムを切り替えるからストレージ効率はいいけど安全性は劣る $ ls /dev/cdrom
/dev/cdrom
$ eject
$ ls /dev/cdrom
ls: '/dev/cdrom' にアクセスできません: そのようなファイルやディレクトリはありません
/dev/cdromはディスクが入ってる間しか存在しないのか？
eject -t でトレイを閉じれないじゃないか ダメだね 数秒後にはなくなる
alias eject='eject /dev/sr0'
にして解決してる >>683
それ、マシンスペックが脆弱なんだろ 笑 >>676
mkinintcpio.confのmoduleにamdgpu書いてる？ debianのupdate-alternativesと同じようなことををarchでやる方法は無いのかな？
手動でlink貼るしかないのか >>691
すまん解決したの報告してなかった。ディスプレイの環境変数をzshrcにwsl用に書いてたのを環境分けてなかった。完全に俺のせい >>692
community/dpkg に入ってる模様 >>695
debian では postinstall スクリプトで登録してる処理コマンドを管理したい対象に自力でやる。
ま、ln で自前でやる方が楽かも知れんけどね。 ArchベースのSteamOSが搭載されたSteam DeckがValveから発売
https://www.steamdeck.com/ >>697
WINEで動かすとかではなく、
SteamのライブラリがクロスプラットフォームだからOSはLinuxでも良いってことか。
PCだとスペックと値段は良いけど、携帯ゲーム機だと値段が厳しそう。 >>698
WINEから派生したProtonで動かしてるんじゃね >>698
仰るとおり、Protonというので動かしてるようだね
Valveこんなことやってたのか >>698
仰るとおり、Protonというので動かしてるようだね
Valveこんなことやってたのか proton関係のレスは殆ど俺や、あまりこのスレでは使われてない感覚ある glancesのアプデで依存関係増えたのに追加されてないっぽい？
pacmanでpython-defusedxml入れたら動く thinkpad T480にgnome入れたんだが、libinputの設定がよくわからなくて
ジェスチャーが使えない。それでendeavor にかえたらすんなりいったんで
しばらくendeavorをメインにすることにした。 日記 NVIDIA 470いい
ようやくOptimus環境でまともにゲームできる >>705
まだ自分の環境だとinteluhdより遅いゲームがあるわ…dxvkが悪いのか？ なんか突然タブつきアプリ（kateとかdolphinとか）のタブ部分とかで常時マウスホイール上に回した様な症状になったわ
firefoxはならんのだがgtkアプリでもなる
マウスの異常かと思ってバラしたら壊しちゃったんだが
別のマウス繋いでも異常だしポート変えても再起動してもアプデしてもなおらん… みんなトラブルもなけりゃ話題もない
保守しないとこのスレ落ちんじゃね？ｗ 半年ぶりにアップデートしたけどなんの問題もなかった。 ■ このスレッドは過去ログ倉庫に格納されています
