Macports настолько хороши или плохи, как мне кажется? [закрыто]
Среди Linux, поддержание обновлений с помощью MacPorts показалось мне больше всего похожим на Gentoo (возможно, наименее похожая на Mac запись в коротком списке основных дистрибутивов Linux).Но после дальнейшего опыта кажется, что это не совсем похоже на Gentoo: с Gentoo что-то ломается регулярно, но вы часто можете найти решение, погуглите значимые части сообщения об ошибке, и в отличие от компьютерных ситуаций в целом имеет вполне рациональный смысл попробовать еще раз. 24 или 48 часов спустя, если что-то сломается. В этом отношении MacPorts похож на Gentoo в том смысле, что вы можете получить поломку, пытаясь поддерживать свою систему в актуальном состоянии, как задумано.
Более ранняя поломка заставила меня задуматься о том, как установить Django; теперь у меня установлен Django, но он ломается при обновлении glib1; последнее существенное изменение ошибки ( http://trac.macports.org/ticket/21413 ) было около года назад.
Действительно ли MacPorts « Ломается как Gentoo, но вы не можете исправить это, как Gentoo », или он говорит: «32-битный? Наследие! Фуу!» или что-то другое? Я хотел бы знать, что такое нормальная базовая перспектива и чего мне следует и чего не следует ожидать от MacPorts. (Или если я ответил на свой вопрос тем, что сказал выше.)
Это столь же плохо. Единственная причина это не хуже, чем Вы, воображает, то, потому что Домашнее пиво (http://mxcl.github.com/homebrew/) представило его устаревший, если у Вас нет некоторого мазохистского требования завинчивать Ваши пакеты со временем и время снова.
Домашнее пиво не могло бы иметь богатства пакетов, которые имеет MacPorts, но это доберется там, и достаточно просто переделать, должны Вы так быть наклоненными, до такой степени, когда добавление, что "формулы" для новых пакетов являются бризом.
Мое личное мнение: MacPorts (как проект) откусил еще много, чем он может жевать. MacPorts по-видимому пытается включать абсолютно все от мира Linux, и к сожалению он заканчивается с бесчисленными пакетами, которые не имеют никакой заботы о них, чтобы удостовериться, что они на самом деле работают. Вещи повреждаются и остаются поврежденными, иногда постоянно.
Вместо того, чтобы тратить впустую мое время с MacPorts или Fink, я теперь рассматриваю следующие три возможности, когда я хочу запустить программное обеспечение с открытым исходным кодом на Mac:
- Если существует определенный для Mac установщик, я использую его.
- Если нет никакого установщика, но проект, как известно, работает над Mac OS X, я создаю его из источника. (Это столь же легко как в реальной системе Linux, если Вам установили XCode.)
- Если это, как известно, не работает над Mac, или если существует слишком много странных зависимостей, я выполняю его в реальной виртуальной машине Linux на моем Mac.
-
1Пятно на, но по крайней мере, MacPorts может быть полезным перед № 2, но после № 1. Много вещей, которым позволяет работа - но стоит перед нею. Если бы OP использует MacPorts как Вы, использовал бы абсолютный диспетчер пакетов (в этом случае, перевозка), не попытка соответствовать стандартам. – Andrew M. 29 September 2010 в 06:42
-
2@Redmumba Определенно допустимая опция. Я лично предпочитаю № 2, потому что я нахожу, что это имеет более предсказуемые результаты, но если MacPorts на самом деле работает, это могло бы сэкономить Вам время. – Skyhawk 29 September 2010 в 19:10
Разработчики MacPorts прилагают все усилия, чтобы протестировать в различных системах и поддерживать несколько конфигураций. Обычно существует поддержка последних двух релизов Mac OS X, в данный момент это - 10,5 Leopard и 10,6 Snow Leopard. Это даже все еще работает над 10,4 Tiger как платформа прежней версии, но никакие дополнительные усилия не будут приложены к этому, чтобы поддерживать новые функции.
Для этого жизненно важно не полагаться на версию системы, но установить зависимости в префикс MacPorts. Это могло бы привести к большим спискам зависимостей, но это - лучший способ сохранить совместимость. Кроме того, Вы получаете более новую версию, чем Apple могла бы предоставить их систему, которая часто не обновляется.
Как пользователь необходимо всегда искать и сообщать проблемах сборки в системе отслеживания ошибок как иначе, специалист по обслуживанию не мог бы знать, что они существуют. Или Вы могли отправить патчи, которые делают процесс интеграции быстрее или даже принимают maintainership для нескольких портов сами. Команда MacPorts всегда нуждается в новых обновлениях порта содействия специалистов по обслуживанию или новых портах. Для Вашего сравнения число разработчиков огромно на хинду, где на MacPorts только горстка людей активно работает над основой и портами. Поэтому занимает больше времени изолировать и устранить проблемы. Помните, что все специалисты по обслуживанию вносят свое время бесплатно в проект.
Для Вашей проблемы в частности, Вы проверяли свою установку build_arch в macports.conf, как предложено в комментариях билета, который Вы связали? Значение по умолчанию build_arch является x86_64 на Snow Leopard. Выполнение чистой 32-разрядной установки MacPorts возможно, но не поддерживается. Рекомендуется следовать инструкциям по миграции в деталь.
Будет программное обеспечение, которое абсолютно не может скомпилировать для 64-разрядного (например, вино), но MacPorts автоматически восстановит зависимости с +universal вариантом. Этот вариант означает, что будет поддержка нескольких архитектуры в единственном двоичном файле или библиотеке.