「MacOSX WorkShop/10.6」の版間の差分

2010年3月8日 (月) 05:47時点における版

MacOSX_WorkShop 10.6 (SnowLeopard) 対応 tree に関する情報

最新バージョン：α

方針

Carbon 非依存へ：Snow Leopard x86_64 ではついに非サポート
X11 依存からの脱却：X11 上での日本語環境メンテに手が回らないのと、Cocoa native のツールで優秀なものが揃ってきたため。
Universal Binary は PPC PP64 を除いた以下の２つに削減。
- configure に与える --host --build --target を工夫して、cross compile の沼からの脱却に成功。

Mach-O universal binary with 2 architectures
(for architecture i386):	Mach-O executable i386
(for architecture x86_64):	Mach-O 64-bit executable x86_64

VineLinux 5.0 を基準にする。
- rpm, apt, TeX 周辺等

rpm-4.8.0 への移行に難渋。GNU extended な strndup() 等があったり、なぜか basename() でこけたり db4 関連でつまづいたりしたのは、パッチを作ったりして解決した。

Cocoa Emacs (23.x)

一応動いてはいるけれど、mew の動作が緩慢。。-nw での動作は問題なし。

gcc 4.4.3 に更新
OpenFOAM を新規採用予定

おしらせ

Snow Leopard リリースが2009年9月にされるのに伴い OSXWS も対応を致します。

現在 apt-rpm の基幹部分の開発が終わった所です。全体の構成は Leopard 版を踏襲する予定ですが、大きな改善を施す絶好の機会ですので、ご意見をお持ちの方は是非議論にご参加ください。

大変お待たせしましたが、現在鋭意開発中です。現在α版状態です。インストーラは以下になります。

http://www.bach-phys.ritsumei.ac.jp/OSXWS/SnowLeopard/MacOSX-WS-10.6.1.dmg

Mac Wiki は出来る限り見る様にしますので、ご要望等有りましたら宜しくお願い致します。

既知の不具合

Snow Leopard 版開発メモ

Xcode

3.2 が付属。 gcc は 4.2.1

$ /usr/bin/gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646)

3.2.1 がリリースされ、10.6 に正式対応。

autotools

$ glibtool --version
ltmain.sh (GNU libtool) 2.2.4

$ autoconf --version
autoconf (GNU Autoconf) 2.61

$ automake --version
automake (GNU automake) 1.10

guile

guile が

 223: 65* [load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1"]

/usr/osxws/share/guile/1.8/srfi/srfi-1.scm:223:1: In procedure dynamic-link in expression (load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1"):
/usr/osxws/share/guile/1.8/srfi/srfi-1.scm:223:1: file: "libguile-srfi-srfi-1-v-3", message: "file not found"

といって動かない。すると gnutls が作れず lftp が作れなくなる。しょうがないので --disable-guile でしのいだ。

最近の autotools も動きが微妙で、cross compile させるのが難儀している。

X11

xmkmf imake がない！Xaw3d 依存の gv などに影響するが、、もう、いい加減、レガシーな X11 apps は Obsoletes しようかしら。
- psを直接見る機会も少なくなりましたしpdfファイルに変換できますので、 gv を無くしても大丈夫だと思います。-Seto
- 瀬戸さん、コメントをありがとうございます。Obsoletes しようと思います。--Tkoba

基本的に X11 アプリは縮小させる方向にします。少なくとも X11 上での日本語ハンドリングはサポートしないことにします。

xgraph は設計が古いため特にポインタ周辺の 64bit への対応が非常に面倒になっています。32bit 版のみの提供にします。

Terminal.app と X11 の親和性が良くなったので mlterm, ~/.xinitrc を廃止。

gtk2

X11 をやめて、gtk+ Mac OS X へ移行
- Pango が ATSUI を利用していて x86_64 Snow Leopard で問題がある事が判明。CoreText へ移行するまでは保留。

AquaTerm

古い 1.0.1 のソース中の NS_HANDLER を @try{}@catch{}@finally{} に変更して 10.6 へ移植した。

OSXWS 10.5 との関係

10.5 から上書き update で CarbonEmacs はそのまま動いて mew でメールも使える。
10.5 版のインストーラーで「一応」そのままインストール可能。

OSXアプリの扱いについて

これから増えていくであろう/Applications/OSXWS/以下のアプリケーションについて考えています。apt-getでのバージョン管理を想定していない個々のアプリは、メニューバーの「アップデートを確認...」以外にも、起動時に確認したり、環境設定内に確認ボタンがあったりします。小林さんは、OSXWSでインストールするアプリは、こういった機能を無効化して配布するとのことでしたが、マイナーアップデートの度に書き換えて配布するのも大変かと思います。また、ユーザがapt-get dist-upgradeを実行する頻度よりも、アプリケーションを立ち上げる頻度のほうが多い場合も想定されます。ということでせっかくアプリケーション内に用意されたアップデート機能は利用したほうがいいと思っています。

OSXは、管理者＝ユーザというシチュエーションがもっとも一般的ですが、OSXWSは大学などの端末で管理者が一括管理できるということも想定しています。OSXのユーザは、通常ユーザと管理者の2種類が用意されていますが、OSXWSは/usr以下にファイルを置くためsu権限が必要という状況です。まず、大きな違いではないですが、/Applications/OSXWS/以下のアプリのアクセス権をsu権限ではなく、OSXの管理者ユーザ権限でインストールしておいてもいいのではないでしょうか？一般的なユーザはこのような動作を期待していると思います。

また、OSXアプリは、もともと依存関係などの不整合は考えられないので、バージョン管理もユーザがアップデートしている可能性もあるけど、apt-getでも一括でupdateできるというポリシーでうまくいくような気がします。マルチユーザ環境での、通常ユーザはいずれにせよアップデートする権限はないですし。--Seto

瀬戸さん、ご意見をありがとう御座います。折角のご意見ですが、これは受け入れる訳にはいきません。なぜならば、OSXWS は「利用環境」としての一貫性を持たせる必要があるからです。apt-rpm で管理されているものは、一貫して apt-rpm の DB との一貫性を保たなければ「環境」全体の整合性が保証できなくなってしまいます。これは MacOSX ネイティブの Cocoa アプリでも事情は同じです。そもそもなぜ /Applications から /Applications/OSXWS に Cocoa/Carbon アプリを移動したのかを振り返ってみてください。ユーザーが自分の手でインストールするものとかぶらないようにする為です。同様に /Applications/OSXWS 以下をOSXの管理者ユーザ権限でインストールするのも意味がありません。また、OSX アプリも依存関係はあります。eb や oniguruma 等の lib, framework は独立した別パッケージで、複数のツールから利用されています。

重要な事は、OSXWS の利用者が戸惑わないようにする事（フェイルセイフの思想）と「環境」の一貫性を保証する事、です。

それを考えると、アプリケーション独自の自動アップデート機能を省くのが最もリーズナブルです。手間はそれほどではありません。--Tkoba

解説有り難うございます。OSXWSの方針について理解しました。ユーザからみると、OSX標準アプリのように見えるのが一番ということですね（iPhoneアプリのノウハウで、Appleがソフトウェア・アップデートを一般開発者に解放するのがベストですかね？）。私の上の考えは、これまでの経験でいくつかのアプリケーションの最新版に差が生じたため、別に自分でインストールしたものを使う状況だったため、その一番スマートで手間がかからない解決方法は何かという問題からでした。ちなみにMacPortのCocoaアプリも、アクセス権や/Application/MacPortsに置くという方針はOSXWSと同じですが、アプリ毎のアップデート機能はそのままにしてあります。--Seto

せっかくですから少しだけ議論を続けさせてもらいます。混乱を避けるためには、OSXWSの一貫性は大切ですが、実用上は個々のアプリの「最新」にばらつきを出さないことも重要だと思います（タイムラグが短ければいいですが数週間の遅れは起こりえます）。ドラッグ＆ドロップでインストールできるタイプのアプリケーションは、最新バージョンにする手段が複数あっても（削除などを許さなければ）、具体的な問題が生じないように思うのですがどうでしょうか？アップデートの重複をさけるため、またより壊れ難いシステムを作るには、ユーザによる更新もInfo.plistをみてDBに反映できるようにするのが一番かもしれませんが。--Seto

もう一度、なぜ/Applications から /Applications/OSXWS に Cocoa/Carbon アプリを移動したのかをよく考えてみてください。自分自身で手で管理をする人ならば、普通に /Applications にドラッグ＆ドロップで入れて貰えればよいだけのことです。わざわざ OSXWS 管理下のものを手で弄る事を可能にするのは労多くして益殆ど無しです。

実際の OSXWS の利用者（計算機に詳しくない私の近くの物理屋さん）の利用状況を見ると、一旦仕事の環境ができてしまうと不具合が生じない限り、手元のソフトのバージョン等は気にしないものです。そのような大多数の利用者が戸惑わないようにするには、利用者の不意の操作が OSXWS 管理下にあるものの一貫性と整合性を崩さないようにしなければなりません。少なくとも、OSXWS で入れたものを普通に使っているだけなのに OSXWS で構築した環境の整合性が損なわれる事態は避けねばなりません。

瀬戸さんの思い描いている状況の良さはわかりますが、OSXWS の最も重要視する視点は「利用者が計算機のお守りから解放されて自分自身の仕事に集中できる環境を作る事」にあります。ここが他のディストリビューションと一線を画するところだと自負しています。このことと、私自身のリソースで実現できる範囲内に物事を収めるバランスが大事です。--Tkoba

今回の提案について不採用了解しました。私信のほうでも、背後にある設計思想から丁寧に説明して頂き有り難うございました。--Seto

osxwsディレクトリの場所について

現在OSXWSの主要なファイルは /usr/osxws 以下に置かれていますが、この場所を/osxws に変更することについて検討していただけないでしょうか？これは以前に却下された意見だったような気もしますが、改めて再検討して頂ければと思います。OSXWSだけで完結する理由ではなく、単に他に合わせてみてはという提案です。 MacPortが /opt/以下に、Finkが /sw/ 以下に、そして、Apple のDeveloper Toolが /Developer/以下にファイルを置いています。一方、osxws の場所は Finder を使って見る事のできない /usr/ 以下に置かれています。複数のディストリビューションを同時に利用することが推奨されないとしても、ユーザにとっては他と似ているというのは状況を把握するのが楽になりますし、Finderから見るだけでOSXWSがインストールされたシステムであることが一目瞭然になります。

- MacPorts は /opt/local 以下に入ります。/opt は慣習的によく使われていて、例えば Intel コンパイラが /opt/Intel を利用します。FYI - ぜ

議論と要望

OSXWS 10.6 に対する要望などが御座いましたらコメントを戴ければ幸いです。議論の上、必要であれば採用させて頂きます。

TeX で euc で書かれたソースをplatex2pdf-eucでコンパイルしようとすると，jsarticle.clsを処理できないようです．ソースがutfなら問題ありません．10.5では両方処理できていたように思うのですが，可能なら対処していただけると嬉しく思います． --121.2.219.143 2010年3月7日 (日) 07:33 (UTC)
- jsarticle.clsの文字コードが10.5のときは JIS でしたが、10.6では utf8 になっているみたいですね。もし今すぐに必要ということでしたら、/usr/osxws/share/texmf/ptex/platex/js/jsarticle.cls を TeX のコンパイル作業をするディレクトリにコピーして、その文字コードをJISに変更されると良いと思います。--Seto

emacs を terminal.app から立ち上げるとフォーカスがemacsに移動しないようです．Finderから立ち上げると問題ないようですが． --121.2.219.143 2010年2月27日 (土) 02:20 (UTC)
- ご連絡をありがとうございます。この問題は当方も認識しており、これは現在の 23.1.93 のバグだと思います。正式リリースの 23.2 では修正されるのではないかと思います。--Tkoba

いつもお世話になっております．ngraphを使い始めて気が付いたのですがレジェンドの日本語が表示されないようです．英文の入力は支障がないようです． --121.118.82.87 2010年2月22日 (月) 06:27 (UTC)
- ご連絡をありがとう御座います。MacOS X も 10.6 になり、そろそろ X11 からの脱却を考える頃かと思います。一応 ngraph も準備する予定ですが、mjograph 等への移行を始めるよていです。--Tkoba

Cocoa Emacs では utf-8m.el が動作しません。Emacs 本体に同等機能があるはずなので、不要だと思います。 --ぜ 2010年1月19日 (火) 05:16 (UTC)
- いつも有り難うございます。銭谷さんのリリースと同様、最初は CarbonEmacs のみでスタートしようと思います。 Cocoa Emacs 開発時の ToDo に入れておきます。--Tkoba
- と書いた舌の根も乾かぬうちに何ですが、やはり Snow Leopard では Carbon はなかなか面倒くさそうです。いま Cocoa Emacs の状態を確認しています。--Tkoba

いつもお世話になっています。OSXWS 10.5 から bash-completion パッケージがなくなったようですが、再録して頂けないでしょうか？ --133.19.126.5 2009年12月15日 (火) 07:00 (UTC)
- ご連絡をありがとう御座います。復活させる方向で作業致します。--Tkoba

お待ちしておりました！テストなどできる限り協力しますので，アナウンスよろしくお願いします． --133.5.165.65 2009年12月1日 (火) 09:07 (UTC)