Urpm-tools - набор утилит для инструментария urpmi

[taaroa]

вам как-то будет по-другому от осознания того, что выше написанное есть ересь mvp?

[DrakSoul]

Исходя из того, что есть на данный момент - оптимального варианта нет.
Необходима четкая структура построения - ее нет. Плюс к тому же необходимо отслежавать содержание
пакетов и его место в структуре построения. Так как изменяя фундамент, можно обрушить все здание
А это возможно, если будет один дистрибютив и одно сообщество, без желания отдельных личностей заработать на этом деньги.

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

З.Ы

У меня нет желания гнать на линукс, но и лгать себе, так же желания нет.

[taaroa]

DrakSoul
изучайте корни -- реестр не есть виндовс. это НАСТОЯЩИЙ юникс. да, всё прописано --- свойства, привилегии и прочее...
единая база. ну, в школе это не преподавали...

[olelukoie]

Мне представляется оптимальным вариант, когда базовые компоненты каждой подсистемы, необходимые для ее нормального функционирования, были бы выделены в отдельные базовые мета-пакеты, и эти мета-пакеты никогда не попадали бы в категорию сирот,

Они, как правило, и не попадают, потому что от них редко что-то зависит (за исключением, иногда, других метапакетов). Другое дело, что они улетают при удалении любого из пакетов, от которых они зависят (после чего и возникает куча сирот). Этого можно было бы избежать, если бы использовались мягкие зависимости.

Во-первых, некоторые мета-пакеты (например task-kde) уже сейчас содержат только мягкие зависимости.
А во-вторых, я Вам предлагаю провести маленький натурный эксперимент. Создайте chroot с мандривой, установите в него мета-пакет basesystem, а затем мета-пакет task-kde с опцией --no-suggests. После этого удалите task-kde4, затем запустите urpme --auto-orphans и посмотрите, какие среди сирот окажутся мета-пакеты. Вы увидите, что среди них будут и task-kde-minimal, и task-x11. Так вот я считаю, что этого быть не должно. Эти мета-пакеты должны остаться (т.е. не должны расцениваться как сироты) независимо от того, что зависящий от них мета-пакет более высокого уровня (task-kde) был удален.
А чтобы убедиться в том, что task-kde не содержит жестких зависимостей, кроме task-kde-minimal, после описанных выше манипуляций выполните urpmi task-kde4-minimal и посмотрите на вывод urpme --auto-orphans. Этот вывод должен оказаться пустым. Другой вариант - посмотреть на содержимое spec-файла. Несложно увидеть, что все строки Requires, кроме одной, относятся к пакету minimal.

выдавалось бы соответствующее предупреждение

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

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

[Bizdelnick]

Создайте chroot с мандривой, установите в него мета-пакет basesystem, а затем мета-пакет task-kde с опцией --no-suggests. После этого удалите task-kde4, затем запустите urpme --auto-orphans и посмотрите, какие среди сирот окажутся мета-пакеты. Вы увидите, что среди них будут и task-kde-minimal, и task-x11. Так вот я считаю, что этого быть не должно. Эти мета-пакеты должны остаться (т.е. не должны расцениваться как сироты) независимо от того, что зависящий от них мета-пакет более высокого уровня (task-kde) был удален.

С какой это радости? Если я хочу KDE, то я ставлю task-kde4 и получаю его. Если я потом решаю, что мне не нужен KDE, то я сношу task-kde4 и сирот, и остаюсь без KDE - всё логично. Если я решу после установки полного KDE, что мне нужен только минимальный (хотя такое не особо часто бывает), то я сделаю urpmi task-kde4-minimal (он пометится, как установленный вручную), удалю task-kde4 с сиротами и получу желаемое. Все возможные варианты легко получить, зачем что-то менять?

task-kde не содержит жестких зависимостей, кроме task-kde-minimal

Значит, я отстал от жизни. Мандривы сейчас под рукой нет, так что проверить ничего не могу. Однако сие означает, что жалобы ManDrive и Hooliganos относились к Mandriva <= 2010.1, где мягких зависимостей не было. В таком случае я категорически не понимаю, из-за чего сыр-бор.

[Bizdelnick]

в восьмой nt

[offtop]Когда это она ушла дальше 6.x?[offtop]

[ans]

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

100%

[olelukoie]

Если я хочу KDE, то я ставлю task-kde4 и получаю его. Если я потом решаю, что мне не нужен KDE, то я сношу task-kde4 и сирот, и остаюсь без KDE - всё логично...

Все верно, я же написал, что каждый способ имеет как достоинства, так и недостатки. Но вот сейчас в состав жестких зависимостей пакета task-kde-minimal входят такие жизненно необходимые для работоспособности кед пакеты, как konsole, ark, kwrite и gwenview. Попытка удалить любой из них приведет к тому, что последующий urpme --auto-orphans снесет всю графику системы, оставив только голую консоль (в лучшем случае, с учетом единственного DE). А то, что я вместо kwrite могу использовать kate, равно как и rxvt вместо konsole или gqview вместо gwenview - никого не колышет. А ark - это вообще убожество, и, кстати, является очень хорошим кандидатом на приложение рук разработчиков из РОСЫ, раз уж они так любят модифицировать кеды. Думаю, что если бы они занялись доработкой ark, все были бы довольны. Просто потому, что сделать хуже, чем есть, им уже не удастся, но может получиться и значительно лучше.

task-kde не содержит жестких зависимостей, кроме task-kde-minimal

Значит, я отстал от жизни. Мандривы сейчас под рукой нет, так что проверить ничего не могу. Однако сие означает, что жалобы ManDrive и Hooliganos относились к Mandriva <= 2010.1, где мягких зависимостей не было. В таком случае я категорически не понимаю, из-за чего сыр-бор.

Сыр-бор из-за кривых и избыточных зависимостей (см. ответ в первой части поста).

[Bizdelnick]

в состав жестких зависимостей пакета task-kde-minimal входят такие жизненно необходимые для работоспособности кед пакеты, как konsole, ark, kwrite и gwenview. Попытка удалить любой из них приведет к тому, что последующий urpme --auto-orphans снесет всю графику системы, оставив только голую консоль (в лучшем случае, с учетом единственного DE).

Стало быть, зависимости task-kde-minimal надо тоже заменить на мягкие.

ark - это вообще убожество

Архивы открывает - что ещё от него нужно?

[olelukoie]

ark - это вообще убожество

Архивы открывает - что ещё от него нужно?

Ну, как минимум, нужно:
1. Тестирование целостности архивов, их восстановление (по возможности) и извлечение неповрежденных файлов
2. Возможность извлечения нескольких отдельных файлов или папок по выбору одной операцией перетаскивания, а не каждый файл по отдельности
3. Пребразование одного типа архива в другой
4. Настройка параметров сжатия при созании архива (возможно где-то и есть, но при создании архива из контекстного меню в дельфине настроек нет)
5. Возможность создавать самораспаковывающиеся архивы (p7zip и линуксовый rar эту фичу поддерживают) и возможность преобразования обычных архивов в самораспаковывающиеся и обратно
6. Возможность задвать/удалять пароль для уже созданных и создаваемых архивов

[romkaromka]

Просто надо в Установку и Удаление программ внести изменения и не сообщать о сиротах как то было в 2009 году. Пользователь не знает и не бредит.

[Bizdelnick]

Просто надо в Установку и Удаление программ внести изменения и не сообщать о сиротах как то было в 2009 году. Пользователь не знает и не бредит.

Если по уму, то надо наоборот добавить возможность сразу удалить сирот или пометить их как установленные вручную. Прямо в GUI.

[romkaromka]

Если по уму, то надо наоборот добавить возможность сразу удалить сирот или пометить их как установленные вручную. Прямо в GUI.

Мне вариант 2009 года больше нравится. Нет сообщения - нет проблемы.

[olelukoie]

Если по уму, то надо наоборот добавить возможность сразу удалить сирот или пометить их как установленные вручную. Прямо в GUI.

Мне вариант 2009 года больше нравится. Нет сообщения - нет проблемы.

Думаю, сокрытие информации - плохой метод. Пользователь все равно рано или поздно узнает про возможность удаления сирот, а про опасность этого действия он узнает неколько позже, когда решит опробовать свои новые знания на практике. Так что этот подход всего-лишь сдвинет момент удаления почти всей системы на более позднее время, и не более того.
Кроме того, появятся пытливые умы, которые захотят выяснить, почему это при установке какой-нибудь digiKam было съедено несколько сотен метров, а после ее сноса освободилось всего несколько десятков. Результат, которого эти умы добьются, вполне предсказуем.

[akdengi]

Вопрос- почему это никого не волнует в Windows? Или в других ОС. Надо убрать режим "сирот" для простых пользователей.

[Bizdelnick]

почему это никого не волнует в Windows?

А что, в ней таки сделали зависимости и перестали дублировать одни и те же файлы для каждой установленной программы?

Или в других ОС.

В Debian, например, волнует. aptitude по умолчанию норовит всех сирот снести, если это вовремя не пресечь. А в Fedora, скажем, не волнует, потому что такая фича в принципе не входит в базовый функционал пакетного менеджера.

Надо убрать режим "сирот" для простых пользователей.

Как справедливо было отмечено выше, всё равно докопаются. Надо сделать его максимально безопасным, а не прятать.

[romkaromka]

Надо и спрятать, и улучшить, сделать максимально безопасным.

[akdengi]

почему это никого не волнует в Windows?

А что, в ней таки сделали зависимости и перестали дублировать одни и те же файлы для каждой установленной программы?

Системные DLL-ки защищены от удаления и не дублируются + механизмы защиты от сноса нерадивыми приложениями. Есть это, есть...

Или в других ОС.

В Debian, например, волнует. aptitude по умолчанию норовит всех сирот снести, если это вовремя не пресечь. А в Fedora, скажем, не волнует, потому что такая фича в принципе не входит в базовый функционал пакетного менеджера.

Я и говорю, что надо убрать

Надо убрать режим "сирот" для простых пользователей.

Как справедливо было отмечено выше, всё равно докопаются. Надо сделать его максимально безопасным, а не прятать.

C 2009 года безопасным не получается. Точнее в рамках замкнутого репозитория и с мягкими зависимостями теоретически возможно. А если перейдем на множество реп? Сейчас уже уход от Main репы приводит к интересным кросслинкам и прочей радости. Лучше убрать, а остальное уже под личную персональную ответственность (типа соглашения :P). Не прочел, снес систему, сам злобный буратина...

[Hooliganos]

Вопрос- почему это никого не волнует в Windows? Или в других ОС. Надо убрать режим "сирот" для простых пользователей.

В Windows это не волнует никого потому, что удалить необходимые для системы модули задача непростая, некоторые удалить в принципе невозможно, некоторые можно удалить, только если сильно постараться (обладая при этом достаточными знаниями о системе и задавшись целью именно порушить систему), а некоторые можно удалить запросто, но они тут же будут восстановлены из dllcache.
А режим сирот надо не убирать, а доводить до ума. Чтобы удалялись пакеты, от которых никто больше не зависит, а не всё подряд, чем пользовалась удаленная программа.

[SinClaus]

А для этого нужно, что бы майтайнер не указывал в зависимостях целиком пакеты (и макропакеты), а вдумчиво перечислял необходимые разделяемые библиотеки... А установщик должен обладать ПОЛНОЙ базой разделяемых библиотек и их зависимостями.
Кто возьмётся?

[Bizdelnick]

Я и говорю, что надо убрать

Я им пользуюсь чуть ли не каждый день. Мне что, вручную зависимости, поставленные для сборки какого-нибудь пакета, сносить?

А если перейдем на множество реп?

А если без "если"? Что-то я не замечал такой тенденции в Мандриве. Чтобы это стало реальным, нужен аналог launchpad или OBS, а его нет и в ближайшее время не предвидится.

нужно, что бы майтайнер не указывал в зависимостях целиком пакеты (и макропакеты), а вдумчиво перечислял необходимые разделяемые библиотеки... А установщик должен обладать ПОЛНОЙ базой разделяемых библиотек и их зависимостями.

Между нами говоря, майнтейнер не указывает зависимости от библиотек ни в каком виде, они находятся автоматически. А у установщика вполне себе полная база репозиторных пакетов.

[olelukoie]

А для этого нужно, что бы майтайнер не указывал в зависимостях целиком пакеты (и макропакеты), а вдумчиво перечислял необходимые разделяемые библиотеки... А установщик должен обладать ПОЛНОЙ базой разделяемых библиотек и их зависимостями.
Кто возьмётся?

Нет, все это не надо, поскольку большая часть этого в функционале rpm была если и не всегда, то очень давно. При сборке rpm-пакета все его зависимости от разделяемых библиотек прописываются автоматически и вполне грамотно. От разработчика требуется только указать те зависимости, которые нельзя разрулить автоматически, типа зависимости одной прикладной или системной проги или утилиты от другой. И у установщика такая ПОЛНАЯ база зависимостей есть. Называется "база данных rpm". В уже установленной системе лежит в /var/lib/rpm .

Проблемы возникают как раз из-за кривой реализации определения сирот. Если пакет не был установлен вручную и от него никто не зависит, то он сирота. Если пакет входит в цепочку зависимостей только пакета-сироты, то он тоже сирота. И как только идет удаление мета-пакета, помеченного как установленного вручную, система сносится почти целиком.
Мое решение: разделить пакеты системы на различные уровни (базовая система, иксы, DE, приложения, разработка на различных языках), для каждого уровня создать свой мета-пакет или группу мета-пакетов (как сейчас для уровня DE - мета-пакеты KDE, GNOME, LXDE...) и никогда их не удалять автоматически. Если пользователь захотел удалить такой мета-пакет вручную - пожалуйста, но автоматом - ни-ни. Плюс некоторое количество предупреждений при удалении мета-пакетов базовых уровней. После такого разделения на уровни можно уже будет говорить о мягких и жестких зависимостях. Например, для базовых уровней все зависимости только жесткие, а для прикладных - только мягкие, за исключением зависимостей от более низких уровней.

Я и говорю, что надо убрать

Я им пользуюсь чуть ли не каждый день. Мне что, вручную зависимости, поставленные для сборки какого-нибудь пакета, сносить?

Вы что, каждый раз после сборки пакета полностью сносите все установленные для него devel-пакеты, а при сборке следующего ставите их заново? Я вот этого никогда не делаю, как поставил один раз devel-пакет, так он у меня и живет всегда. А если надо сделать чистую сборку (что бывает крайне редко), то есть chroot...

[Bizdelnick]

Вы что, каждый раз после сборки пакета полностью сносите все установленные для него devel-пакеты, а при сборке следующего ставите их заново?

Нет, только при сборке нового пакета. Чтобы удостовериться, что все BuildRequires прописал правильно. Или когда корень переполняется. Или перед обновлением кукерной системы, чтобы не тянуть лишние пакеты. В общем, ситуаций, когда надо снести сирот, масса.

[Flint71]

я конечно не гуру, но... а вы пробовали сделать так:
1. удаление пакета
2. просмотр списка сирот(если они есть)
3. reboot компа
4. обновление источников
5. запрос на список сирот
6. сравнить результаты п.2 и п.5
???????

[olelukoie]

я конечно не гуру, но... а вы пробовали сделать так:
1. удаление пакета
2. просмотр списка сирот(если они есть)
3. reboot компа
4. обновление источников
5. запрос на список сирот
6. сравнить результаты п.2 и п.5
???????

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

[Bizdelnick]

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

Может или покажет? Вообще-то не должно, поскольку по идее учитываются зависимости уже установленных пакетов, а не тех, что в репозитории.

[olelukoie]

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

Может или покажет? Вообще-то не должно, поскольку по идее учитываются зависимости уже установленных пакетов, а не тех, что в репозитории.

Ну да, просто я понял фразу в п.4 как обновление системы с помощью urpmi --auto-update. Обновлять репы и не устанавливать обновленные пакеты особого смысла не имеет. Если же речь шла только про обновление реп без установки обновленных пакетов, то конечно отличий быть не должно...

[Flint71]

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

последовательность действий надо делать сразу же после пп.1-3.. а не после "аптайма" в несколько часов... конечно лучше перед выполнением п.1 сделать обновление источников пакетов.. :-)

[taaroa]

в восьмой nt

[offtop]Когда это она ушла дальше 6.x?[offtop]

подразумевалась microsoft ® windows ® 8&#153; на ядре nt6.2.
p.s. праздники закончились... всё съедено.

[taaroa]

А режим сирот надо не убирать, а доводить до ума. Чтобы удалялись пакеты, от которых никто больше не зависит, а не всё подряд, чем пользовалась удаленная программа.

в gentoo это хорошо реализовано... но даже там есть возможность отстрелить себе конечности при бездумном [да] [y] или полностью автоматическом depclean.
если делать что-то аналогичное, то, опять-таки, обязательно наличие аналогов revdep-rebuild и ко.