LINUX.ORG.RU

Интервью с лидерами Fedora: Max Spevack и Paul Frields

 , ,


0

0

Макс Спивак последние 2 года был лидером проекта, и вот он решил уйти, а на его место пришел Paul Frields.

Макс появился в RedHat в 2004 в подразделении Red Hat Network. Спустя какое-то время он смог познакомиться и поработать с Matthew Szulik и Michael Tiemann. И как только у него появилась возможность, он окунулся с головой в работу коллектива Fedora. В его задачу входило составление планов и корректировка работы, повышение роли Fedora внутри самой RedHat, работа со средствами массовой информации.

Что касается Поля, то он говорит, что за время работы рядом с Максом он узнал огромное количество новой уникальной информации. Он познакомился с такими людьми, как 'бриллиант' Dimitris Glezos - человек, который знает о локализации всё. Fedora является для RedHat инкубатором инноваций. Начиная с 2005 года происходит эволюция как в самой Fedora, так и в отношении к ней. Репозитории, инфраструктура и система билдов Fedora поставили ее в ряд ведущих инновационных дистрибутивов Linux, сделали её платформой, в которой каждый может внести личный вклад в общее дело.

Макс в первую очередь горд за т.н. инструментальную систему билдов (Koji + Pungi). Live CD и Live USB реализованы также на достаточно высоком уровне. За это время RedHat нанял в свой штат изрядное количество волонтеров из рядов Fedora, которые продолжили свою работу уже в рядах компании, но все на ту же Fedora.

В ближайшее время Макс будет занят созданием т.н. CommunityArchitecture команды, в задачу которой входит широкое массовое распространение глобальной девелоперской стратегии. Эта работа будет связана с командировками в Европу, Южную Америку, с формированием там лидерских команд, спонсирования их материально.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от Tigro

> а он говорит, вот блин а я не могу найти то, что тот пакет хочет.

Подключишь репозитарии необходимые. Не тупи. Yum конечно же из астрала достанет необходимые зависимости и предоставит работающий пакет?

anonymous
()
Ответ на: комментарий от mv

Тебе правда нужно накидать примеров в которых yum'у и rpm просто не хватит функциональности в сравнении с apt и dpkg?

Между aptitude и apt-get в большинстве обычных случаев можно поставить знак равенства. К тому же apt это намного более широкий набор утилит чем просто apt-get.

anonymous
()
Ответ на: комментарий от mv

> Пакетный менеджер должен работать с пакетами, мой анонимный друг.

Правильно. В Debian-based дистрибутивах, dpkg - это низкоуровневый менеджер пакетов, а apt - это высокоуровневая система работы с репозиториями и пакетами.

Apt - это именно система, а не программа. А aptitude и apt-get - это как раз утилиты для работы в этой системе. Почитай man'ы, т.к. ты не понимаешь что есть что.

Если тебе что-то из моих слов не понятно, то пересиль своё слабоумие и прочитай документацию на пакетную систему в нелюбимом дистрибутиве.

anonymous
()
Ответ на: комментарий от mv

>Т.е. работа ведётся через один yum, а не через вагон с тележкой разносола.

Что оплачивается снижением быстродействия в дополнение к небыстрому питону?

anonymous
()
Ответ на: комментарий от anonymous

> Что оплачивается снижением быстродействия в дополнение к небыстрому питону?

Ха-ха. Ты из тех, кому кажется, что пересборка софта конкретно под твою машину реально ускоряет его?

mv ★★★★★
()
Ответ на: комментарий от mv

>Им не понять, что стандартизация покладёт на все per-distro финтифлюшки и у всех будет стоять LSB-compliant пакетный менеджер.

А что тебе не известны примеры когда apt прикручен к rpm? Или yum каким-то боком указан в lsb? ALT и PCLinuxOS к примеру вполне на уровне смотрятся среди прочих дистрибутивов. К тому же мы еще о формате пакета даже не начинали спорить, только о менеджерах. Сливай.

anonymous
()
Ответ на: комментарий от anonymous

Я не это имел в виду. Я имел в виду тот факт, что при yum install пакет.rpm он все осмотри и скажет, что не может удовлетворить зависимости по причине отсутствия таких-то вещей. А через dpkg мы пакет влепим, потом поймём что что-то не так, потом придётся его сносить. Настоящий Unix-way получается, занимающий слишком много времени.

А если этим занимаются девелоперы, так они вообще ничего не заметят и пойдут своими делами заниматься. А не убив этот пакет или не удовлетворив зависимости в системе вообще ничего поставить больше нельзя.

Tigro ★★
()
Ответ на: комментарий от mv

>Читай: http://www.debian.org/doc/FAQ/ch-pkgtools.en.html

И? Aptitude хорош когда нужно застолбить пакет - вот функциональность dselect привнесенная в него. Я отношу это скорее к необычным случаям. В остальном аптитуда - интерфейс к apt-get.

anonymous
()
Ответ на: комментарий от Tigro

>APT умеет ставить локальный .deb пакет (чтобы зависимости разрешились)?

элементарно создать локальный репозитарий либо тупо кинуть имеющиеся deb пакеты в /var/cache/apt/archives/

xtron
()
Ответ на: комментарий от mv

>Анонимусы вот чего-то вылезли. Им не понять, что стандартизация покладёт на все per-distro финтифлюшки и у всех будет стоять LSB-compliant пакетный менеджер

дебиановской стандартизации 100 лет в обед! И где она, там же, где и дебиан!

anonymous
()
Ответ на: комментарий от anonymous

> А что тебе не известны примеры когда apt прикручен к rpm?

И?

> Или yum каким-то боком указан в lsb?

В LSB будет указан не apt и не yum

> К тому же мы еще о формате пакета даже не начинали спорить, только о менеджерах. Сливай.

Назовись для начала. А потом будем спорить о возможностях. Только, по всей видимости, ты не умеешь содержимое (формат) от возможностей отличать.

mv ★★★★★
()
Ответ на: комментарий от mv

> yum при установке rpm с локального диска не будет портить базу установленных пакетов, и её не надо будет чинить другой утилитой.

Во-первых, не съезжай с темы, речь шла именно о "потом apt-get -f install, а он говорит, вот блин а я не могу найти то, что тот пакет хочет." То есть человек предположил ситуацию, что в зависимостях будут пакеты, которые не сможет найти apt, а следовательно их нет ни в репозитории, ни локально.

Во-вторых, установка левого софта _должна_ портить базу!! Потому как пакетная система в Debian - это единый организм, а не свалка пакетов. Пакеты, взятые неизвестно откуда юзер устанавливает на свой страх и риск, рискуя получить неудовлетворённые зависимости и пакетная система ему об этом сообщает.

anonymous
()
Ответ на: комментарий от xtron

xtron мне друг, но истина дороже.

Первый вариант гемороен ибо dpkg-scanpackages делать приходится каждый раз. Второй будет работать только с пакетами инфа о которых имеется в базе (apt-get update).

anonymous
()
Ответ на: комментарий от anonymous

> Ну не будет он тогда устанавливать пакет, пока ему не подсунешь правильный путь.

Ну товарищ Tigro кричал, что yum рулит и умеет сам находить зависимости и ему не нужно ничего подсовывать. Вот пусть отвечает за свои слова.

> А ваш любимый apt в федоре тоже присутствует. Пробовал его. Дерьмо редкое.

Так дело же не в apt, а в Fedor'e ;)

anonymous
()
Ответ на: комментарий от anonymous

> Между aptitude и apt-get в большинстве обычных случаев можно поставить знак равенства. К тому же apt это намного более широкий набор утилит чем просто apt-get.

С yum тоже много утилит полезных идет, на базе его ядра. repoquery, package-cleanup, yumdownloader и т.д.

anonymous
()
Ответ на: комментарий от mv

>Назовись для начала.

Не вижу причины по которой мне нужно это делать. Мишуру о приличиях и манерах оставьте при себе. Важно не авторство, а смысл слов.

>Только, по всей видимости, ты не умеешь содержимое (формат) от возможностей отличать.

Ты вспомнил lsb. Я тоже вспомнил, что там регламентировн формат rpm, afaik. При этом не указывается однозначно какой пакетный менеджер я должен использовать. Т.е должны стоять определенные пакеты (rpm, alien) но это не мешает мне использовать более другие менеджеры. Т.е в твоем сообщении я rpm воспринимал как формат. Объясни, где я ошибся?

anonymous
()
Ответ на: комментарий от mv

> Им не понять, что стандартизация покладёт на все per-distro финтифлюшки и у всех будет стоять LSB-compliant пакетный менеджер.

Да ты и в LSB не шаришь. Откуда ты такой взялся??! Объясняю: Стандарт не навязывает операционным системам, какой формат им использовать для собственных пакетов. Он лишь говорит, какой формат совместимые системы должны поддерживать для установки приложений сторонних разработчиков. Так как в Debian присутствует опциональная поддержка LSB, проблема исчезает при более близком рассмотрении (то есть пользователь всего лишь должен использовать утилиту alien для преобразования и установки сторонних пакетов). Таким образом, на практике Debian совместим с LSB.

anonymous
()
Ответ на: комментарий от anonymous

>С yum тоже много утилит полезных идет, на базе его ядра. repoquery, package-cleanup, yumdownloader и т.д.

Найдешь, скажем, аналог apt-build?

anonymous
()
Ответ на: комментарий от Tigro

> А через dpkg мы пакет влепим, потом поймём что что-то не так, потом придётся его сносить.

Я уже говорил, что если кто-то ставит пакеты неизвестного происхождения, то это его личные половые проблемы. Пакетная система не отвечает за действия дебилов, такие могут и путём ./configure && make && make install ставить софт и разводить помойку. Так что Ваши претензии просто беспочвенны.

anonymous
()
Ответ на: комментарий от Tigro

> А если этим занимаются девелоперы, так они вообще ничего не заметят и пойдут своими делами заниматься.

Да Вы что? Хреновые девелоперы какие-то, раз не могут понять, что у софта не удовлетворены зависимости.

anonymous
()
Ответ на: комментарий от mv

>koji, brew

Это действительно умеет установку srpms с разрешением всех зависимостей? По-моему ты привел нечто уровня dpkg-buildpackage.

А нечто вида apt-ring, который предоставляет аутентификацию по личному ключу разработчика, дабы предотвратить компрометацию пакета, yum имеет?

anonymous
()
Ответ на: комментарий от Tigro

>Да, с подобными теоретиками спорить бессмысленно.

Если тебе не интересна беседа, то думаю лично я потеряю немного от твоего ухода.

Ребят, хочется адекватной инфы, а не вашего слива. Честно.

anonymous
()
Ответ на: комментарий от Tigro

> Да, с подобными теоретиками спорить бессмысленно.

Да, да.. А Вы нашли одну функцию yum'a, которая работает в apt по другому и уже разорались, что yum - рулит, а apt - фигня. Между тем, Вы сознательно закрываете глаза на недостатки RPM и yum, так как у вас личная предрасположенность именно к RedHat-based дистрибутивам и Вы не хотите признать, что apt во многом лучше пакетной системы красношляпых.

anonymous
()
Ответ на: комментарий от anonymous

> Это действительно умеет установку srpms с разрешением всех зависимостей? По-моему ты привел нечто уровня dpkg-buildpackage.

Кхм...

mv ★★★★★
()
Ответ на: комментарий от anonymous

Ты просто не понимаешь для чего подобные вещи нужны и когда их применять. Я попытался объяснить, но ты упорно считаешь что любой пакет, которого нет в Debian левый и не достоин того, чтобы быть установленным в системе. Заводишь болтовню про make install какую-то и про "свой страх " и риск. Ну не хочешь, не надо.

Tigro ★★
()
Ответ на: комментарий от anonymous

Да, ладно это шутка была, там кажись смайлик стоял, но этой функции не хватает в самом деле.

Tigro ★★
()
Ответ на: комментарий от anonymous

Мне, честно говоря, пофиг. Я на столько редко ставлю пакеты, что мне без разницы, во сколько раз yum тормознее apt.

На счёт форматов (deb vs rpm). Что конкретно есть в deb, чего нет в rpm?

mv ★★★★★
()
Ответ на: комментарий от Tigro

> Ты просто не понимаешь для чего подобные вещи нужны и когда их применять.

Да Вы что? Вы наверное заболели манией величия с тех пор как делаете репозитории на Яндексе. На вопросы отвечать считаете ниже своего достоинства и отшучиваетесь советами сходить на лекции Столлмана. Потрудитесь снизойти и привести аргументы, а не пустые звуки типа "yum - рулит, а apt - сосёт из-за того, что там имеется возможность поставить пакет без зависимостей".

anonymous
()
Ответ на: комментарий от mv

> Что конкретно есть в deb, чего нет в rpm?

Навскидку: debtags (поиск по тэгам, очень удобно), apt-file (поиск файла по всему репозиторию), debian-keyring (цифровые подписи каждого пакета, исключающие атаку man-in-the-middle), autoremove (автоматическое удаление неиспользуемых пакетов) и т. д.

anonymous
()
Ответ на: комментарий от anonymous

> Навскидку: debtags (поиск по тэгам, очень удобно)

Я про формат пакетов. debtags provides a system to download a database of package tags and keep it up to date.

> apt-file (поиск файла по всему репозиторию)

$ yum whatprovides /bin/bash bash.x86_64 : The GNU Bourne Again shell (bash) version 3.2

> debian-keyring (цифровые подписи каждого пакета, исключающие атаку man-in-the-middle)

Удивили... А где их нет? В Enterprise Linux? Они там как бы не раньше появились.

> autoremove (автоматическое удаление неиспользуемых пакетов)

package-cleanup -q --leaves | xargs yum -y remove

$ rpm -qf `which package-cleanup` yum-utils-1.1.11-1.fc8

> и т. д.

Пока ничего уникального не привели

mv ★★★★★
()
Ответ на: комментарий от mv

Хочу внести свои 5 копеек.

Шапкой я занимаюсь давно ( с 5-ки )
и вот как то давно решил попробывать Debian
( наслушался тогда Витуса про его круть )

Ставлю пакет - а он мне начинает вопросы задавать ... не понял
какие это вопросы то ? Я же эту инфу узнаю после инсталяции
командой man... и не покатил у меня дебиан !

Позже я правда узнал что есть якобы ключ что бы вопросы не задавать
но уже лень было пробывать.

Меня устраивает подход шапки - по умолчанию для меня оптимально а если что я маны почитаю и руками подправлю ! Но как правило это не требуеться.

И раз уж зашел спор ( бесмысленный ) про deb vs rpm
то вот мне интересно если аналог в дебе - drpm ?
( ответ : что оно не нужно - засчитываеться как слив ! )

--
mx

anonymous
()
Ответ на: комментарий от anonymous

>И где она, там же, где и дебиан!

В заднице, чтоли? У дебиана нету шансов. RedHat раздавит быдл.

anonymous
()
Ответ на: комментарий от anonymous

> Ставлю пакет - а он мне начинает вопросы задавать ... не понял какие это вопросы то ? Я же эту инфу узнаю после инсталяции командой man... и не покатил у меня дебиан !

Какой же ужасный этот Debian!! Вздумал какие-то вопросы задавать! :))

Если он и задаёт какие-то вопросы при установке, значит это действительно нужно. Ты конечно, можешь устанавливать пакеты с опцией --force-yes, тогда он у тебя вообще ничего не спросит, но потом.. далее цитата из мана: "force-yes can potentially destroy your system!". Решать тебе, кем тебе быть: power юзером или тупым ССЗБ.

Если это были вопросы о конфигурировании, то ты всегда можешь переконфигурировать уже установленный пакет при помощи dpkg-reconfigure.

В общем, признайся, что просто не осилил и/или у тебя не хватило ума, и то, что у тебя интеллектуальные проблемы ещё не значит, что Debian - плохой дистрибутив. Да и нормальные люди, обычно, перед использованием какой-то технологии, читают документацию, чтобы потом не ломать голову над возникшими трудностями. Для этих целей существует http://debian.org/doc/

> вот мне интересно если аналог в дебе - drpm ?

Имеешь в виду deltarpm? Существует. Называется debdelta.

anonymous
()
Ответ на: комментарий от anonymous

> Да и нормальные люди, обычно, перед использованием какой-то
> технологии, читают документацию, чтобы потом не ломать голову над
> возникшими трудностями.

Да согласен может я не осилил Дебиан.
Но есть небольшой парадокс почему то в Шапке на 90 процентов
( по крайне мере у меня ) все работало без вопросов и как надо.
Конечно можно про одно почитать про другое и тд и тп
Но мое мнение ( это только мое ) что ось/дистрибут нужен для конечного
пользованияа не для оси ради оси.
Опять же если мне захочеться/нужно что либо исправить и почитать я это
всегда могу сделать позже ! И почему то правка конфигов руками в этом
случае для меня удобнее чем : reconfigure пакет.

> Называется debdelta

ок. Спасибо.
--
mx

anonymous
()
Ответ на: комментарий от mv

>> debtags (поиск по тэгам, очень удобно)

> Я про формат пакетов.

Да будет тебе известно, что стандартные утилиты apt-cache и aptitude выводят тэги пакета даже в том случае, если пакет debtags не установлен, поэтому можно считать, что это уже стандартная фича apt.

>> apt-file

> $ yum whatprovides

Всегда думал, что он ищет только среди установленных пакетов. Но если он ищет по всему репозиторию, это, конечно, плюс.

>> debian-keyring (цифровые подписи каждого пакета, исключающие атаку man-in-the-middle)

> Удивили... А где их нет? В Enterprise Linux?

Ха-ха.. С каких пор Fedora считается Enterprise Linux? :D Да и для меня так и осталось загадкой, поддерживает ли yum проверку цифровых подписей пакетов.

>> autoremove

> package-cleanup -q --leaves | xargs yum -y remove

Ну вот, начинаешь противоречить самому себе, пару постов назад ты писал: "работа ведётся через один yum, а не через вагон с тележкой разносола": http://www.linux.org.ru/view-message.jsp?msgid=2555537#2557127

Чего же ты сам решил вести работу через вагон разносола?! Советую написть в баг-трекер Федоры, чтобы они срочно включили функционал package-cleanup в yum!!

anonymous
()
Ответ на: комментарий от anonymous

> Но мое мнение ( это только мое ) что ось/дистрибут нужен для конечного пользованияа не для оси ради оси.

Да, Debian не претендует на звание самого user-friendly дистрибутива, это ведь и не первоочередная задача его сообщества. Но ведь существует огромное число дистрибутивов, основанных на Debian, которые в первую очередь стремятся завоевать десктопы обычных пользователей, например, Ubuntu. А внутри, Ubuntu - это тот же Debian, просто переделан специально для того, чтобы с ним было легко работать даже человеку далёкому от IT.

anonymous
()
Ответ на: комментарий от anonymous

> Да будет тебе известно, что стандартные утилиты apt-cache и aptitude выводят тэги пакета даже в том случае, если пакет debtags не установлен, поэтому можно считать, что это уже стандартная фича apt.

Не знаю, как он это делает, но в паре просмотренных .diff.gz никакой информации от тегах нет. Что-то слабенький ты дебианоид какой-то...

> Ха-ха.. С каких пор Fedora считается Enterprise Linux? :D

Причём здесь Федора? Речь про формат пакетов идёт. Федора, кстати, тоже с подписанными пакетами.

> Да и для меня так и осталось загадкой, поддерживает ли yum проверку цифровых подписей пакетов.

А вы почитайте документацию. Хотя, вы даже от своего дистрибутива не читаете, что это я?..

> Ну вот, начинаешь противоречить самому себе, пару постов назад ты писал: "работа ведётся через один yum, а не через вагон с тележкой разносола": http://www.linux.org.ru/view-message.jsp?msgid=2555537#2557127

Ну это же unix-way! Вдруг мне просто надо посмотреть пакеты без референсов, без их сноса? Кстати, я помню те времена, когда apt не умел autoremove и приходилось всякими deborphan пользоваться.

> Чего же ты сам решил вести работу через вагон разносола?! Советую написть в баг-трекер Федоры, чтобы они срочно включили функционал package-cleanup в yum!!

Ты какой-то jerk. С форматами пакетов и с системами их управления ты слился, дорогой.

mv ★★★★★
()
Ответ на: комментарий от mv

> Я про формат пакетов. Мелочь, конечно, но... упаковка - читстый ar против модифицированного cpio. Можно повспоминать и посравнивать классы зависимостей, но думаю ни к чему. Не так это важно. Думаю, сейчас на достаточном уровне автоматизирована и сборка из исходников в rpm с чем раньше лично я имел проблемы. Коренные отличия, на мой взгляд, все же нужно искать в полиси. У дебиана политика почетче. Можно выделить два лагеря у deb. Сам debian и ubuntu, но и они синькаются все-таки. И все потомки дебиана крепко на его репах сидят и не создают велосипеды. А в стане rpm такого единства имха нет (или я слишком давно не юзал rpm-дистрибутивы?!). Suse, RHEL, Mandriva - разного поля ягоды.

>$ yum whatprovides /bin/bash bash.x86_64 : The GNU Bourne Again shell (bash) version 3.2

И конечно тебя устраивает скорость работы этой функции?! Ну-ну.

>Удивили... А где их нет? В Enterprise Linux? Они там как бы не раньше появились.

Да вот как бы нигде и нет, afaik. Ты понимаешь, речь не просто про банальный md5-хэш. Мы с товарищем анонимусом говорим про ключ который у каждого разработчика/мейнтейнера свой, им он подписывает сопровождаемые пакеты. Понимаешь смысл?

Брат-анонимус какая-то нездоровая штука. Я размышляю практически аналогично тебе. Это анонимусо-специфично, последствие работы с дебианом или просто у дураков мысли сходятся?

We are the Anonymous. You will be assimilated.

anonymous
()
Ответ на: комментарий от mv

Многоуважаемый mv, вот скажи мне, быдлоанонимусу, начистоту. Почему появляются крупные дистрибутивы-проекты "поставим аптом рпмку", но ни одного на слуху основанного на сентенции "зафигачим юмом деб-пакет"? Потому что деб так плох или все-таки юм недостаточно хорош?

anonymous
()
Ответ на: комментарий от mv

> Не знаю, как он это делает, но в паре просмотренных .diff.gz никакой информации от тегах нет.

А ты посмотри в файлах в каталоге /var/lib/apt/lists ;)

>> Да и для меня так и осталось загадкой, поддерживает ли yum проверку цифровых подписей пакетов.

> А вы почитайте документацию.

А почитай сам. Цифровая подпись пакета и файлик с MD5-хешами внутри пакета - это разные вещи ;)

Первое спасёт тебя от подмены пакета, второе - нет.

> Ну это же unix-way!

Неужели ты понял?! Молодец!

> С форматами пакетов и с системами их управления ты слился, дорогой.

Я просто считаю, что рассматривать одно отдельно от другого - бессмысленно.

anonymous
()
Ответ на: комментарий от mv

> С форматами пакетов и с системами их управления ты слился, дорогой.

Ха-ха, кто из нас сливает? Скорее тот, кто наивно полагает, что yum умеет проверять цифровые подписи пакетов ;)

anonymous
()
Ответ на: комментарий от anonymous

> И конечно тебя устраивает скорость работы этой функции?! Ну-ну.

$ time yum whatprovides ghc ghc.x86_64 : Glasgow Haskell Compilation system ghc.x86_64 : Glasgow Haskell Compilation system

real 0m1.648s user 0m1.399s sys 0m0.182s

Да, устраивает. На фоне sbcl собирается.

> Да вот как бы нигде и нет, afaik. Ты понимаешь, речь не просто про банальный md5-хэш. Мы с товарищем анонимусом говорим про ключ который у каждого разработчика/мейнтейнера свой, им он подписывает сопровождаемые пакеты. Понимаешь смысл?

Понимаешь, Fedora - это нифига не независимый проект. Это RedHat. В RedHat у мейнтейнера нет ключей для подписи пакетов, это делает система во время релиза. gpg-sign в rh с хрен знает каких времён. Я прекрасно помню времена, когда в дебиане подписей не было. И это было не так давно.

Примерно 70% своей работы с линуксом я провёл на Дебиане (пакетов насобирался достаточно). По работе столкнулся с продуктами rh (тоже собирал пакеты :), понял, что системы по возможностям одинаковые. Но у rh есть деньги и желание заработать ещё больше денег, поэтому в плане технических решений сиськи они мнут гораздо реже, чем в Дебиане :)

mv ★★★★★
()
Ответ на: комментарий от anonymous

> Скорее тот, кто наивно полагает, что yum умеет проверять цифровые подписи пакетов ;)

О чём с тобой говорить, зашоренный ты наш?

mv ★★★★★
()
Ответ на: комментарий от anonymous

> Многоуважаемый mv, вот скажи мне, быдлоанонимусу, начистоту. Почему появляются крупные дистрибутивы-проекты "поставим аптом рпмку", но ни одного на слуху основанного на сентенции "зафигачим юмом деб-пакет"? Потому что деб так плох или все-таки юм недостаточно хорош?

Потому что это opensource. Если есть силы реализовать желания - никто не запрещает. yum всего несколько лет назад был печальным зрелищем, появился apt-rpm. Сейчас yum не сильно хуже apt по скорости, по возможностям примерно одинаковы.

mv ★★★★★
()
Ответ на: комментарий от anonymous

> А ты посмотри в файлах в каталоге /var/lib/apt/lists ;)

Я смотрю в корень проблемы, т.е. в исходники для сборки пакетов. Информации о тегах там нет.

> А почитай сам. Цифровая подпись пакета и файлик с MD5-хешами внутри пакета - это разные вещи ;)

Блин, когда я чего-то не знаю, я иду читать документацию. Почему же другие этого не делают?... В rh и производных gpg-подписи есть, и уже давно.

> Я просто считаю, что рассматривать одно отдельно от другого - бессмысленно.

Да, пиво без водки - деньги на ветер.

mv ★★★★★
()
Ответ на: комментарий от mv

> Я смотрю в корень проблемы, т.е. в исходники для сборки пакетов. Информации о тегах там нет.

Представь себе, система тегов - вещь динамичная, теги постоянно дополняются, поэтому их список и не идёт в пакете, они находятся в базе пакетов apt'a, а эта база обновляется после каждого выполнения apt-get update ;)

Идём дальше: в apt существуют "мягкие" зависимости: (Recomends и Suggest), есть возможность указания в зависимостях логического "или", поэтому я говорил, что apt - более продуманная система, разработчики заранее предусмотрели возможные "подводные камни".

anonymous
()
Ответ на: комментарий от anonymous

> Представь себе, система тегов - вещь динамичная, теги постоянно дополняются, поэтому их список и не идёт в пакете, они находятся в базе пакетов apt'a, а эта база обновляется после каждого выполнения apt-get update ;)

Т.к. вопрос был про преимущества ФОРМАТА пакетов, то последние n комментов твоих - фигня не по делу.

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.