[過去ﾛｸﾞ] Arch Linux 16 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
554(2): 2021/06/26(土)21:42 ID:s2E9GxEZ(1) AAS
>>553
notoかな？
Debian11の/usr/share/fonts/を
全部ぶっこ抜いてコピーしたらこうなった。
この手法だとブラウザ含めて全てのフォントがいい感じになるからオススメ。
555: 2021/06/27(日)04:30 ID:f49T7y3v(1) AAS
グラフィックをBIOSで設定できるのはまだましでhpでは一切触れなかった
nvidiaGPU強制有効でVRAM6GBあるのにIGPUも強制有効で強制的に2GB取られる
全く訳がわからない仕様だった
556(1): 2021/06/27(日)23:57 ID:azn9groB(1) AAS
書き換えりゃええやん
557: 2021/06/28(月)04:43 ID:EsHAFnuO(1) AAS
fcitx5あったのか いいこと聞いた
5ってpacmanに明示しなきゃ入らないよね まあいつかはいらんくなりそうだけど
558: 2021/06/28(月)19:18 ID:xfirj+AN(1) AAS
Debian向けのAURが登場したらしい
外部ﾘﾝｸ:dur.hunterwittenborn.com
559: 2021/06/29(火)01:28 ID:cLbtR/gQ(1) AAS
pkgbuidで使えるの？
Linux版のbrewもあるけど、アーチのパッケージシステム使えたらいいよね。
560: 2021/06/29(火)01:32 ID:ASTf7wQP(1) AAS
pacmanクソ有能だからね
561: 2021/06/29(火)03:18 ID:aIQXpDn8(1/2) AAS
てかaurに統一するんじゃなくて、サンドボックス機能があるflatpakしかりsnap然りに統一してほしい感ある
最近pipewireなりwaylandが使えるまでに進歩したし
562: 2021/06/29(火)03:36 ID:xhoVlxJG(1) AAS
Gnomeにしてみたけど言われているほど悪くない
設定でアニメーション切って
なるべくショートカットキーを活用するとサクサク動かせる
初心者向けのDEだと思って使うと面食らうけど
キーボード操作前提の中上級者用のDEだと頭を切り替えて使うとかなり良いね
i3やXmonadの超リッチ版だと思って扱うとめっちゃ快適で
カーネルメンテナ達が愛用するのも納得
563: 2021/06/29(火)10:16 ID:GlAz40C+(1) AAS
i3も悪くないけど、快適かと言われるとね。
564: 2021/06/29(火)11:30 ID:aIQXpDn8(2/2) AAS
i3然りwmで快適じゃ無い点ってなんや？
ノーパソ利用ならwmってクソ神だと思うんだけど…
特に自分的にいい点は、マウス操作するのブラウザくらいでほぼキーボードから手を離さなくて済んだのとtmuxを使わなくなった
565: 2021/06/29(火)12:17 ID:JJH0HNFw(1) AAS
キーボードに慣れるとマウス前提のDEに戻れないのは分かる
Gnomeがキーボードで行けるなら乗り換えもありかな
リーナスやGKHがマウスを頻繁にカチカチしてる姿は想像しにくいし
実際キーボードで完結するんだろうね
566: 2021/06/29(火)17:54 ID:TgrbPNY0(1) AAS
>>554
Noto fontは中・日・韓の言語を包括サポートするnoto-fonts-cjkが多くのdistroの公式
リポジトリにあり、Archにもある[*]。他のdistroから持ってくるとfontがupdateしても使用
distroが知る術がないので、その手法はdistroに含まれないもの以外は、お勧めできない。
公式リポジトリからインストールするには、以下で。
----
sudo pacman -S noto-fonts-cjk noto-fonts-emoji
[*] フォント - ArchWiki
外部ﾘﾝｸ:wiki.archlinux.jp
567(1): 2021/06/29(火)18:15 ID:JjYtfU9f(1) AAS
フォントは抜けがあるだけで一気に汚くなるから
大手のdistroから引っ張ってくるのは効率的ではある
568: 2021/06/29(火)19:28 ID:/x2T8PPO(1) AAS
抜けを気にするならそれこそNotoでいいだろ
569: 2021/06/29(火)20:12 ID:6FTtCe7b(1) AAS
snapにサンドボックス機能があってもあんまり必要なシーンが思いつかない。開発者はDockerで検証すればいいだろうし、性能に響くだけじゃん。
570(1): 2021/06/29(火)20:15 ID:/tW6Hf6k(1) AAS
Dockerとsnapでは抽象化してる層が全然違うやん
571: 2021/06/29(火)20:16 ID:tWHgbqzP(1/2) AAS
フォントは余計なの入れると古いの使われて汚くなることあるわ
JAVAとか汚くなると厄介
572: 2021/06/29(火)20:17 ID:tWHgbqzP(2/2) AAS
コピペで持ってくるのはWindows専用のやつだけ
573: 2021/06/29(火)20:48 ID:1pQGG5Az(1) AAS
>570
何が言いたいかさっぱりわからん。Dockerで安全ならsnapでも安全だと思うけど。
そもそも、パッケージマネージャーがないとサンドボックス運用ができないのが問題じゃなくて?
574(1): 2021/06/29(火)21:16 ID:O9PpGOCh(1) AAS
確かにメリットはよく分からん。
だから全然普及してないんだろうけど。
575: 2021/06/29(火)23:18 ID:czp3iFwB(1) AAS
>>567
ArchもArch系と言われるdistro群の上流に位置する、大手の一つだが。
>>574
Snapは開発しているCanonicalのやり方に一部メンテナが異議を唱えている。LinuxMintの
創設者、Clement Lefebreは上流のUbuntuがChromiumのサポートをSnapに限定した手法の
内容が、ユーザーを欺く行為[*]だとして、Mint20以降、Mintリポジトリからsnapdを削除した。
[*] Linux Mint dumps Ubuntu Snap
By Steven J. Vaughan-Nichols June 5, 2020 18:52
外部ﾘﾝｸ:www.zdnet.com
576: 2021/06/29(火)23:19 ID:wNGTiE7q(1/2) AAS
Ubuntuは一部のシステムすらsnap化してるという記事を読んだことがある
将来のアップグレードでsnap廃止とかになったら作業が面倒くさそうだけどいいのだろうか
577: 2021/06/29(火)23:35 ID:F3IdvQhg(1) AAS
MintはとにかくUbuntuに逆らいたいだけって印象
親に養ってもらいながら親に反発する子供みたいな
578: 2021/06/29(火)23:53 ID:wNGTiE7q(2/2) AAS
リソース足りてないのに上流とコンフリクトする方向に乖離したプロジェクトは消える運命よ
Mintがリソース足りてるのかどうかは知らん
579: 2021/06/30(水)00:16 ID:y47kI9li(1) AAS
mintはシェア落としてるでしょ
ユーザーフレンドリーなディストロが増えてきたから
580: 2021/06/30(水)00:17 ID:gLYGVaur(1/2) AAS
さっさとcleartype対応してくれよいつ特許切れるんだよ
581: 2021/06/30(水)01:41 ID:5eiz5XzA(1) AAS
GNOME 40への対応を見るにUbuntuも色々と弄りすぎて
パッケージ側の大きな更新に追従する余裕がなくなってきてるね
Unityとか自前で作ってた頃と比べると相当開発規模が縮小してそう
582: 2021/06/30(水)05:55 ID:C+qyy0ha(1) AAS
snap嫌いなんだよなあ
fdisk -lがひどいことになる
583: 2021/06/30(水)07:43 ID:F8FbHeK9(1) AAS
ループバックのマウントポイントが大量に出てくるってことかちょっと分かる
584: 2021/06/30(水)14:21 ID:0d70OYTv(1) AAS
大量のハッシュ名ファイルを作るflatpakも嫌い
585(1): 2021/06/30(水)19:30 ID:2x4FXU9Q(1) AAS
バイナリ1つにまとめてくれたら管理が楽なんだけどね
パフォーマンスも考えると難しいか
586: 2021/06/30(水)19:40 ID:rqk2B62B(1) AAS
snap てdockerで動いたっけ？
前にインストールしてダメだった気が。
587: 2021/06/30(水)20:33 ID:gLYGVaur(2/2) AAS
>>585
appimage
588: 2021/06/30(水)20:34 ID:Diadtm22(1) AAS
AppImageは1ファイルで良い感じだけど普及率の低さとアップデートの面倒さが欠点
589: 2021/06/30(水)23:01 ID:hKS9U+yZ(1) AAS
GNOME40試してみたけど
アニメーション無効化したら確かにi3感覚で使えるね
初期設定はtrackerの無効化と端末エミュ起動のショートカット設定くらいで十分
メモリ使用量はそれなりだけど動作速度はラップトップで使っても相当速い
590: 2021/07/01(木)00:23 ID:fIGQc4Eg(1) AAS
使わないメモリは無駄なメモリ
余ってるメモリは積極的にキャッシュとして活用したほうがいい
591: 2021/07/01(木)00:58 ID:YrSedzvF(1) AAS
誰もそんな話してないが
592: 2021/07/01(木)01:24 ID:yz4Mm0BT(1) AAS
ケンカ腰の書き込みはNG
593(1): 2021/07/01(木)05:05 ID:4UzRSbP+(1) AAS
最近思うんだけどArchが壊れる原因って
pacmanのパッケージでの依存関係の定義の甘さもあるよね
アップストリーム追従だから仕方ないけど
公式リポジトリでも依存関係の不足が発生する場合がある
594: 2021/07/01(木)05:55 ID:tcGTizYD(1/2) AAS
いや、yayなりのparuなりの非承認pacmanパッカー使ってるのが原因や‼︎aurutilsを布教したい‼︎
595: 2021/07/01(木)09:49 ID:Gnv3u7aV(1) AAS
>>593
主要なライブラリのアップデートがあると依存するアプリ全てビルドしなおす必要あるから大変やね
外部ﾘﾝｸ:archlinux.org
最近はsonameを公式で追えるようになったから楽になったとはいえ
596(1): 2021/07/01(木)09:50 ID:/QSXLwOS(1/2) AAS
pacmanで壊れるとか言ってる奴でちゃんと再現性のある実例出てきた例がまったくねーよな
いっつも｢〇〇入れたら依存関係がぶっ壊れてぐちゃぐちゃ｣みたいな何の再現性もない曖昧な日記ばっか
使い方も理解しない原因も特定しないでてめぇでぶっ壊して｢ふぇぇ何もしてないのに壊れたよぉぉ｣とか騒ぐんならWindowsでも使ってろやwww
597: 2021/07/01(木)12:47 ID:bcXLFTtz(1) AAS
>>596
何もしなくても強制アップデートで壊れるwindows勧めるとか鬼かよｗ
598(2): 2021/07/01(木)12:59 ID:dVlRXVAk(1) AAS
再現性のある実例ったってArchで再現可能な説明をしようにも
インストール手順から何から全部説明する事になるから困難でしょう
仮に全部説明されたところで常に最新になるからこっち側での再現も無理だし
599: 2021/07/01(木)13:41 ID:tcGTizYD(2/2) AAS
>>598
それな〜各々の環境全然違うから、飽くまで解決の一例又は依存関係のエラー吐かれるって情報が沢山あるだけ有益だと思うけどな〜
寧ろなんも凝って無いインストールガイドこそ要らへんわ
600: 2021/07/01(木)13:51 ID:dGG8Tl8T(1/2) AAS
>>598
> 再現性のある実例ったってArchで再現可能な説明をしようにも
> インストール手順から何から全部説明する事になるから困難でしょう
アホ？
なんですべてのレイヤをごっちゃにして考えるのだ
601: 2021/07/01(木)13:58 ID:RRs9zd38(1) AAS
最近遭遇した例だと、lua52とlua両方のパッケージが入った状態で
vlcをビルドすると失敗するという依存関係での不具合があった。
解決方法はlua52を削除。
依存関係は不足ならまだ分かりやすいけど
上記のような組み合わせて初めて発生するタイプのエラーもあるから厄介。
個々のパッケージの依存関係だけ見ると完全に満たされてるからね。
602: 2021/07/01(木)14:09 ID:dGG8Tl8T(2/2) AAS
ビルドはまた別の話だろ
Arch (pacman) は別に手元でビルドするための依存関係を解決してるわけじゃない
やり直し
603: 2021/07/01(木)15:13 ID:/QSXLwOS(2/2) AAS
本人は具体的に指摘してるつもりなんだろうけど相変わらず｢依存関係での不具合｣とかいうぼんやりした物言いに終始してて草
604: 2021/07/02(金)11:39 ID:jmevyBd5(1) AAS
vlcのビルドで誤ったライブラリを参照されるということであればvlcのバグなのでは
605(2): 2021/07/02(金)12:17 ID:2u+6grQG(1/2) AAS
頻繁に依存関係が壊れるパッケージといえばhaskell関連だな。
archのたまに出てくる依存関係壊すやつは公式の手順どおりに使ってないだけって奴は単純に使ってるパッケージが少ないだけ。
普通に更新切れたパッケージが削除されずに残って依存関係を壊す（パッケージが腐る）こともあるし、経験足りないんじゃないの？
ただそのぐらいの不具合は他のディストリにもあるし、そのぐらいはアーチユーザーが空気吸うみたいに修正して使うから問題にならないだけだ。
606(2): 2021/07/02(金)12:23 ID:2u+6grQG(2/2) AAS
昔からフルビルドして使ってる人からしたらパッケージマネージャーは依存関係の補助でしかなくて、Linuxにインストールするソフトやファイルの位置は自分でコントロールするのが普通でpacmanはそれがやりやすいだけで、依存関係をわざと壊そうとしたら普通に壊せるからな。
Luaのパッケージにしたって危惧すべきことが起きたなあって感じだ。
607: 2021/07/02(金)12:37 ID:YGM+fr54(1) AAS
error while loading shared libraries: libfoo.so.1: cannot open shared object file: No such file or directory
とか言われたら
1. libfoo.so.2とかの似た奴がないか探してもしあったら｢$ ln -s libfoo.so.2 libfoo.so.1｣とかやって自分でシンボリックリンク作ってやる
2. 1がなかったらUbuntuとか別ディストロからlibfoo.so.1.1.1とかをコピーして持ってきて｢$ ln -s libfoo.so.1.1.1 libfoo.so.1｣とかやって自分でシンボリックリンク作ってやる
ってやってやれば良いんやで
ってのはウソやで、どっちもよく見かける間違った対処法だから真似したらアカンで
608(1): 2021/07/02(金)12:52 ID:m1FnR+W2(1) AAS
>>605
cabal使ってて壊れてるならインストールしたいものに依ってはちょっと面倒かもだけどstackage使った方がいい
haskellライブラリ専用のディストリビューションみたいになってて依存関係で壊れる心配がなくなる
609: 2021/07/02(金)15:28 ID:5z+rkvTc(1) AAS
>>608
おっしゃる通り、もうパッケージマネージャーに依存してなくて、stackコマンドで管理してる。
依存関係壊れなくても頻繁にpacmanのビルドが更新されるからアップデート時の負担になるので切り離したほうが圧倒的に楽だった。
610: 2021/07/02(金)17:06 ID:DBS68A5n(1) AAS
stackがない頃 (有名じゃない頃？) に構築した環境そのまま使ってるから pacman まかせだわ
haskel 関係のアプデ多いからウザいっちゃウザいんだよな
今のところ不具合というのはないが
611: 2021/07/02(金)17:25 ID:4REpWDcm(1) AAS
カーネル5.13はどう?
612: 2021/07/02(金)19:52 ID:zkLUfbvq(1) AAS
>>605
本当それですわ
開発とかで大量のパッケージ入れ始めると
pacmanへの信用がなくなる
613(1): 2021/07/02(金)22:35 ID:5DVFBBv5(1) AAS
自分の開発環境とディストリの配布物は混ぜないようにするのが良いとxmonadで学んだ
ちょっと想像すると分かるが、自分のPCで今動いている自作のソフトウェアが本当は何に依存しているのか、把握するのって結構大変よ
614: 2021/07/03(土)00:13 ID:E7G1tF4Z(1/4) AAS
xmonad何かあったんか?
615: 2021/07/03(土)00:21 ID:qdT7U3Eh(1/2) AAS
そりゃ会話の流れ的に、開発用途で入れたライブラリで
Xmonadの方のHaskellの依存が壊れたんでしょ
616: 2021/07/03(土)00:32 ID:E7G1tF4Z(2/4) AAS
開発でHaskellライブラリ使うことあるのか
猛者かね
もう4〜5年近くarch使ってるけど、公式アナウンスされるのとほんの少し程度しか依存関係然りbootしなくなったことねーけどな〜
皆猛者で弄りまくってるからなのか、皆が何も考えず弄ってるのか、はたまた俺が優秀なのか、はたまた俺がなんも弄らんで使ってるから壊れないのか
どれなんだ一体？！
617: 2021/07/03(土)00:32 ID:fjEuxsxS(1) AAS
Archでマイナーな構成にすると
自分しか遭遇しないであろうトラブルにも結構見舞われるから
もう諦めてGNOMEにしてるわ
618: 2021/07/03(土)00:41 ID:qdT7U3Eh(2/2) AAS
実際ソフトウェア開発にはあまり向いてないね
公式の開発環境の導入手順がDebianやfedora用しか紹介されてない事が多いし
619: 2021/07/03(土)06:02 ID:L8Im1wqj(1) AAS
開発とかいう言葉に逃げてるフシがあるが、本当に開発のために夥しい数のかつdevelopingなパッケージをインストールする必要があるなら今はdocker等を検討するべきでしょう
それに、DebianやFedoraは平気なのにpacmanでは解決できてない依存関係というのが本当に存在するなら、抽象的な物言いでなく具体的にいつのどれと言えば良い
>>613とは別人だと思うが、
> 自分の開発環境とディストリの配布物は混ぜない
って何を今更ってくらい当たり前のことですよ
アマチュア開発者さんたちの率先してわけわからんことして喜ぶくせ、本当に良くないよ
620(2): 2021/07/03(土)07:14 ID:XO6FBg0A(1) AAS
ArchはAURで勝手に開発用の依存関係入れてくるから
AURが必要ないようなミニマルな用途じゃない限りは避けられないでしょう
逆に619さんがどういう用途でArchを使っているのか気になるよ
621: 2021/07/03(土)07:24 ID:LKh3nHEM(1/2) AAS
一言に開発と言っても言語やフレームワークによって前提条件異なるからそこの認識合わせないと議論はすれ違い続けるのでは
622: 2021/07/03(土)08:21 ID:E7G1tF4Z(3/4) AAS
それ 情報系言葉の定義が広かったり、多様な意味あったりとで明確な名称で定着してほしいもんだ
623: 2021/07/03(土)08:30 ID:EpVlBR5P(1) AAS
>>620
それが、Archが公式にAURパッケージのインストール補助をしない理由なんですよ
> ArchはAURで勝手に開発用の依存関係入れてくるから
これは言っちゃ悪いが糖質並みの妄言だ
いつどのように「ArchがAURで勝手に開発用の依存関係入れ」たのか説明しろ
逃げんなよ絶対しろ
624: 2021/07/03(土)08:37 ID:KcNL5rFs(1/3) AAS
node.jsだったらnvm使うしrubyだったらrvm使う
それがhaskellだったらstackだったってだけでは
625(1): 2021/07/03(土)09:42 ID:c+sEipgN(1/2) AAS
全部過去の話よ
外部ﾘﾝｸ[php]:wiki.archlinux.org あたりの
日々使うソフトはpacmanで管理したいけど、ちょっと興味が湧くから開発環境も入れるじゃん？
cabal-installとかもとりあえず使ってみるじゃん？
で、しばらくするとcabal-installで入れたもの、それを元にmakepkgしたhaskellのパッケージ、pacmanが管理しているもの
全部が混在することになってpacman -Syuするとghc-pkgが怒る
もちろん、これは「何もしていないのに壊れた」なんて当時も思っちゃいなかったが、「何が悪いのか分からない」状態にはなった。
626(1): 2021/07/03(土)10:24 ID:s4L8YXou(1/5) AAS
言語やフレームワークごとにパッケージマネージャがある場合はどう考えてもディストリのパッケージマネージャとは使い分けるべきだ
pip しかり cabal しかり
使い分けると言っても、単にユーザー環境下 ($HOME 以下) にインストールすることにすれば足る話
これは開発とはまたレイヤの違う、常識やモラルの話だろう
>>625さんは分かっておいでのことだと思うが、他の多くの方はどうもこの点を理解されていない
627: 2021/07/03(土)10:50 ID:aLG59f9B(1/7) AAS
やっぱ結局なーんも理解しないで｢何もしてないのにぶっ壊れた｣って騒いでるだけっていうね
628: 2021/07/03(土)12:01 ID:P3+J52mG(1) AAS
"ぎじゅつりょく"至上主義は頂けないな。
発展性の無い事に頭や時間を使うのは趣味でしか無い事くらい自覚しときなよ。
629: 2021/07/03(土)12:04 ID:g5wTqN0x(1) AAS
ライブラリを共有するのが悪いってことでそれがsnap？
630(1): 2021/07/03(土)13:20 ID:iSU9IFbY(1) AAS
話のきっかけの<<605たけど、
俺は一言も開発環境と言ってなくて、haskellの公式パッケージはたびたび依存関係が壊れるって話。
Rubyもnodejsもシステムのパッケージ壊れないだろ。
ちなみにたまーにglibが壊れるのと同じ理由、原理的に壊れないということはないのよ。
バイナリ配布は難しいのよ。
631: 2021/07/03(土)13:34 ID:aLG59f9B(2/7) AAS
いつんなったら自分がサポート外のことしてぶっ壊してるだけなんだって気づくんだろ
632: 2021/07/03(土)13:50 ID:aLG59f9B(3/7) AAS
相変わらず｢壊れた｣が何を意味してんのかすらはっきり言わねぇからあれだけど
仕組み的にはサポート外のことしなきゃ壊れなくなってるしサポート外のことしてないのに壊れてるならバグレポすればいいだけ
ちゃんと理解してるなら対応も簡単だし今ここでバージョンとかの具体例を上げればいいだけ
理解して無くて｢なんもしてないのに壊れたよふぇぇぇ｣とかしか出来ないから具体例が上げられないんだよな
633(1): 2021/07/03(土)13:55 ID:kIV0YRft(1/8) AAS
ちょっとまって、依存関係が壊れた で何を意味してるかわからないユーザーがいるの？
シングルバイナリじゃないとモジュールに依存して動くんだけど、それが壊れるってだけなんだけど、それがわからないの？？
634(1): 2021/07/03(土)14:14 ID:aLG59f9B(4/7) AAS
>>633
どんだけレベル低いんだよ
ただ｢壊れる｣としか言わねぇんじゃ動的リンク時の話なのかもロード時の話なのか単純にライブラリが見つからないのかとかsonameの付け間違いなのかそれらが上流のバグなのかArchのバグなのかアホユーザーが自分で壊したせいなのかとか腐るほど可能性があって話にならねぇんだよ
だからバージョンなりエラーなり具体的に言えっつってんの
635(1): 2021/07/03(土)14:20 ID:kIV0YRft(2/8) AAS
>>634
なんていうか、おつかれ。俺そんなのはコミュニティに直接報告するからここでは書いても意味ないし、知りたいことは自分で調べるから十分だわ。
説明してマンに説明するぐらいなら開発者に言うわ。
あと大抵、pkgbuildのミスかパッケージ更新のタイミングが殆どの原因だよ。
Haskellはバージョンが変わると基本全部ビルドし直しだから更新のタイミングがずれただけで壊れる。
これ以上は説明する気さえ起きない。調べろ。
636: 2021/07/03(土)14:24 ID:kIV0YRft(3/8) AAS
あと普通はリンクできなくてエラーになるのを依存関係が壊れると言うと思う。
言葉ミスってる奴はいるし、俺はスルーしてる。
他の原因まで考えないそれが普通。
間違ってたら間違ってるよといえばいいだけ。
ロードできないとかは依存関係は壊れてないだろ。
637: 2021/07/03(土)14:25 ID:kIV0YRft(4/8) AAS
勝手に可能性を広げて拡大解釈して意味わからんとか何がしたいか全然わからん。
638(2): 2021/07/03(土)14:28 ID:aLG59f9B(5/7) AAS
な、結局なーんも理解しないで自分でぶっ壊して｢なんにもしてないのに壊れた！｣とか言ってるだけだろ？
639: 2021/07/03(土)14:33 ID:zNOIQjxh(1) AAS
>>638
ちゃんと読めよ。遠回しに否定されてんだろ
640: 2021/07/03(土)14:37 ID:kIV0YRft(5/8) AAS
>>638
<<606
641(1): 2021/07/03(土)14:51 ID:aLG59f9B(6/7) AAS
> あと普通はリンクできなくてエラーになるのを依存関係が壊れると言うと思う。
な、やっぱなーんも理解してない
リンク時にエラーになるっつーのはつまり自分でビルドしてるときの話なわけだがそれはつまり公式の立場から見りゃAURと同じで"サポート外"なわけ
公式のパッケージは依存するライブラリの非互換な変更によるリビルドやパッチの必要性をTODOでリスト化して対応してから一斉にアプデって形がとれるけど
無限にあるユーザーのオレオレビルドオレオレパッチのために公式の側のアプデを遅らせるなんて不可能だからな
んでそれは固定リリースのUbuntuだろうがDebianだろうがリリースが変われば非互換な変更が起きるんで同様の問題が起きる事に変わりはない
642(1): 2021/07/03(土)14:58 ID:LKh3nHEM(2/2) AAS
>>630
golangやrustといった最近の言語が静的リンクデフォルトにしてるのはバイナリ配布難しい問題に対する一つの回答なのかね
言語のランタイムも静的リンクするからコンパイラのバージョンアップでABI/APIが変わっても影響されない
その分ディスク容量は食うわけで富豪的な解決策ではあるが
643: 2021/07/03(土)15:08 ID:kIV0YRft(6/8) AAS
>>642
*nixのモジュール主義は初期のディスク容量の制限からきてるし、当初はみんなビルドしてたから問題なかったし、動的リンクの方が良かった。
今は静的リンクの方がめんどくさくないから当然考えられるオプションだと思うよ。
なるべく依存したくないのはみんな同じだと思う。
644: 2021/07/03(土)15:10 ID:aLG59f9B(7/7) AAS
>>420>>980
次スレは
--------
システムメンテナンス (英語, 日本語)
外部ﾘﾝｸ:wiki.archlinux.org
外部ﾘﾝｸ:wiki.archlinux.jp
--------
も追加してくれ
AURやローカルでのビルドはアプデ時に自分で対応が必要とかの基本的な事もちゃんと書いてある
645: 2021/07/03(土)15:15 ID:kIV0YRft(7/8) AAS
>>641
当然、自分でビルドしてないのに見つからないことがあります。
他人には詳細に前後の関係を求めるくせに、自分は偏見で判断するの良くないよ。
あと依存が壊れたのをアーチの所為には誰もしてない。壊れたと事実を言ってるだけ。
646: 2021/07/03(土)15:22 ID:ICIdujQb(1) AAS
Ubuntuなら壊れないとかDebianならこんな事にはならないなんて誰も言ってないのにそういう声が聞こえるみたいだし、なんかの病気だろうね
647: 2021/07/03(土)15:28 ID:kIV0YRft(8/8) AAS
まあでもHaskellの依存関係が壊れるのは頻繁にHaskellのバージョンを上げてるのが一番の原因だけどな。
関連パッケージが同時に更新されないのも痛い。
Haskellに関してはアーチとの相性が圧倒的に悪い。
あと単純にHaskellが時代遅れ。
xmonad使う層が自分たちで解決しちゃうのもあって初見殺し感もある
648: 2021/07/03(土)15:32 ID:c+sEipgN(2/2) AAS
haskellはビルドした時点で依存関係がガチガチに固まるってことを分かってない人がいるな
今は1000近いhaskellのパッケージをほぼ1人で作成しているんで壊れにくくなってる
が、これってあんま健全じゃない
649: 2021/07/03(土)18:36 ID:H8swIg6H(1/2) AAS
>>606ゥ？？？
> 昔からフルビルドして使ってる人からしたらパッケージマネージャーは依存関係の補助でしかなくて、Linuxにインストールするソフトやファイルの位置は自分でコントロールするのが普通でpacmanはそれがやりやすいだけで、依存関係をわざと壊そうとしたら普通に壊せるからな。
頓珍漢もいいとこだぞ
サポート外のことしか書いてない
650: 2021/07/03(土)18:41 ID:H8swIg6H(2/2) AAS
少なくともID:kIV0YRftがサポート外のことして「壊し」てるのは確定ですね
>>635辺り見てもAURを公式と見なしてるの確定
ID違うが>>620と同じ奴か？
こんだけ言われててなおこんなに基本的なこと分かってない奴が何人もいるって思いたくないのだが
651(3): 2021/07/03(土)19:35 ID:E7G1tF4Z(4/4) AAS
話変わる質問なんだけど、
言語由来のパッケージマネージャーであるpip然りでインストールするより、aurなり公式リポジトリからインストールすべきなの？それとも言語由来のパッケージマネージャーで入れるべき?
652: 2021/07/03(土)19:38 ID:jI2iSlEc(1/7) AAS
誰かHaskellの関連パッケージがAURじゃなくて公式のパッケージって教えてやれよ
653: 2021/07/03(土)19:40 ID:8YjekEVh(1) AAS
>>651
使いたいのがシステム側で使うだけのツールならそれも含めて公式から入れてもいいけどバージョン指定したり最新が良い、公式に無いパッケージも使う開発用なら環境丸ごと仮想化したほうが楽
上下前次1-新書関写板覧索設栞歴
あと 349 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.687s*