Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
На этот форум и wiki ведут ссылки с официальных сайтов Mageia.
У форума нет нигде и никаких чатов, wiki пока не работает (в процессе подключения), идёт небольшая реорганизация.Форум закрывается, подробности в теме «Реорганизация форума».
Mageia Russian Community Forum → Программирование → SNAPPY-CLEANER [очистка системы]
ingvaro, перефразировать меня не надо, и не надо выдумывать как по хитрому использовать запрещённое. Я отразил официальную позицию Mageia.org в её переводе на русский язык. Точка. Они защищаются вплоть до судебных исков, очень строго с этим.
"Mageia" можно использовать, если разработка идёт официально от организации "Mageia.org".
Если не трудно, то объясните что надо сделать, что бы разработка была официально от организации "Mageia.org".
Конечно с точки зрения "Mageia.org"
Сдать экзамены на знания, пройти практику под руководством одного из текущих разработчиков, стать разработчиком, получить соответствующие права, разработку вести в инфраструктуре Mageia, у них свой git.
SnappyCleaner v1.1
1. От обновления к обновлению urpme/urpmq отдают разные списки сирот (--auto-orphans): либо включают старые ядра devel, либо нет. Теперь список старых ядер принудительно исключается из списка сирот, если присутствуют
2. Формируется общий список удаляемых пакетов (ядра + сироты)
3. Каждый пакет удаляется индивидуально во избежании перекрестных зависимостей
4. Имя удаляемого пакета отображается в строке статуса
5. Оптимизированы запросы к базе данных RPM
p.s. После столь оживленной дискуссии, решил не делать татуировку "Mageia" у себя на пупке 
Теперь список старых ядер принудительно исключается из списка сирот, если присутствуют
И это очень правильно, мало ли, чел оставил старое ядро, а потом на автомате случайно удалит
2. Формируется общий список удаляемых пакетов (ядра + сироты)
Вы наверное хотели сказать - 2. Формируется два списка удаляемых пакетов (ядра + сироты)
3. Каждый пакет удаляется индивидуально во избежании перекрестных зависимостей
Подробнее пожалуйста, а до этого как удалялся?
У меня просьба, если конечно без больших заморочек - в окне программы нет возможности что-либо скопировать, добавьте пожалуйста, например требуется скопировать название зависимости
Вы наверное хотели сказать - 2. Формируется два списка удаляемых пакетов (ядра + сироты)
Нет, Именно один из двух: из списка ядер и списка сирот с исключенными ядрами
Подробнее пожалуйста, а до этого как удалялся?
Раньше выполнялись 2 операции urpme --auto для списка ядер и для списка сирот последовательно. Если после удаления ядер удалялись зависимости из списка с сиротами, удаление по списку сирот прерывалось. Сейчас всё делается сверху вниз в одном списке и urpme --auto пакет. Если пакет уже отсутствует, клинер не выходит из цикла, а удаляет следующий по списку. Это дольше - но надёжнее. Как я понял, сама Магия не может гарантировать, какой именно пакет в следующий момент времени окажется сиротой. Именно - гарантировать. В любом случае, выявление этих "предстоящих" зависимостей займёт больше времени, чем urpme --auto пакет.
У меня просьба, если конечно без больших заморочек - в окне программы нет возможности что-либо скопировать, добавьте пожалуйста, например требуется скопировать название зависимости
Хорошо...
2. Формируется общий список удаляемых пакетов (ядра + сироты)
Именно один из двух: из списка ядер и списка сирот с исключенными ядрами
Тогда это следует понимать так - Формируется общий список удаляемых пакетов (ядра + сироты), из списка ядер и списка сирот с исключенными ядрами (визуально в разных окнах, но для программы список один).
Вероятно так?
Если пакет уже отсутствует, клинер не выходит из цикла, а удаляет следующий по списку. Это дольше - но надёжнее.
выявление этих "предстоящих" зависимостей займёт больше времени, чем urpme --auto пакет.
сама Магия не может гарантировать, какой именно пакет в следующий момент времени окажется сиротой. Именно - гарантировать.
ох как всё запутанно, но главное чтобы пакет не удалялся как сирота в тот момент, когда он уже нужен для другого, ведь в зависимость к следующему он не ставился (по причине уже установленного в систему).
Блин, как разобраться в родстве седьмой воды на киселе 
ведь в зависимость к следующему он не ставился
но указан как зависимость у этого пакета.
но указан как зависимость у этого пакета.
TopE, ставится ПАК1+ЗАВ1, в системе он обозначается именно как ЗАВ1 к ПАК1.
Теперь ставим ПАК2 у которого в зависимостях тоже ЗАВ1, но так как он уже установлен, то система его не помечает как ЗАВ2, хотя и имеет ввиду, что он требуется уже для обоих пакетов ПАК1 и ПАК2.
Далее мы удаляем ПАК1, а ЗАВ1 может стать сиротой, а может и не стать - поди разберись в этих urpme/urpmq, я как-то так понял.
Во всяком случае так объяснял diablopc
alex_q_2000, только сейчас обратил внимание на небольшую нелепицу, при проверке сироты на зависимости открывается два окна:
1.ТребуЕтся для пакета: и 2.Сам пакет требуется для: (получается что пакет требуЕтся в обоих списках, хотя в первом требуются ему, а во втором ОН сам требуется другим)
Первое окно, это перечислены пакеты требующиеся, например для sudo :
urpmq --requires-recursive sudourpmq --whatrequires sudo
или 2-я команда с уточнением установлен/не_устанорвлен
for i in $(urpmq --whatrequires sudo); do rpm -q $i; doneможет стать сиротой, а может и не стать
не станет, так как он указан в зависимостях к ПАК2
не станет, так как он указан в зависимостях к ПАК2
ой ли
но так как ЗАВ1 уже был установлен, то инфа о нем не обновляется.
У меня просьба, если конечно без больших заморочек - в окне программы нет возможности что-либо скопировать, добавьте пожалуйста, например требуется скопировать название зависимости
Добавлено копирование в буфер отдельных позиций и выгрузка списков в файлы (перезалил повторно 1.2)
ой ли
если система не помечает его как зависимость пак2, то грош цена функции удаления сирот и про нее надо просто забыть и не использовать вообще.
если система не помечает его как зависимость пак2, то грош цена функции удаления сирот и про нее надо просто забыть и не использовать вообще.
TopE, а в Магее и нет такой фукции и никогда не было, единственное что есть так это самая первая пометка зависимости при первоначальной установке пакета. Дальнейшей судьбой пакета urpme/urpmq не занимается - никто её на это не настраивал.
но зато это попытался сделать alex_q_2000, может быть не совсем до конца, но хотя бы так, что уже очень хорошо.
Вероятно задача будет решена полностью, когда программа или система будет отмечать переход зависимости от одного пакета к другому. Таким образом автоматом решится вопрос - сирота пакет или нет.
alex_q_2000, сегодня случайно создал пустую папку и удалил её в корзину, но программа её почему-то не очистила, хотя текстовый файл(не в папке) удалила.
зы: я тебя ещё не замучил своими тестировками?
а в Магее и нет такой фукции и никогда не было
если честно, то я не сильно разбираюсь в кишках магии по этому поводу, но насколько я знаю в ванильном rpm принципиально не должно оставаться пакетов сирот, если пакетный менеджер правильно следит за зависимостями. Это только в deb -дистрибутивах с мягкими зависимостями такое возможно.
Раз всё упирается в трудности с отслеживанием зависимостей сирот в списке потенциальных сирот, пусть Магия сама отслеживает эти зависимости по шагам.
Предлагаю удалять выбранные пакеты без зависимостей через rpm -e --nodeps имя_пакета. В теории мы получаем результат, сходный с работой CCleaner, когда за один проход он гарантированно удаляет отмеченные ключи реестра, но не удаляет связанные с ними. При повторном сканировании он выдаёт список оставшихся от удалённых. Там приходится запускать анализ/очистку несколько раз, поскольку каждый раз он выдаёт всё меньше и меньше зависимостей (ключей). Обычно 2-3 прохода бывает достаточно.
Таким образом, если логика работы urpmq --auto-orphans вернА, мы пошагово приблизимся к идеалу чистой системы, просеивая зависимости сирот через сито rpm. Этот вариант раза в 3 быстрее, чем urpme --auto имя_пакета и позволяет более детально исследовать зависимости пакетов. Что скажете?
p.s. Сам процесс удаления становится более динамичным и предсказуемым. Для тестов выложена версия 1.3. Истина где-то рядом. ))
Для тестов выложена версия 1.3.
Пустую папку из корзины не очистила
Пустую папку из корзины не очистила
Сейчас поставлю 5.1 x64 KDE, проверю и выложу видео
alex_q_2000⇓ пишет:Для тестов выложена версия 1.3.
Пустую папку из корзины не очистила
Видео очистки корзины от мусора в Mageia 5.1 KDE x86_64
По поводу rpm -e --nodeps ничего не добавите?
С уважением,
alex_q_2000
alex_q_2000, я мог бы точно такое же видео выложить, где программа не видела этой папки.
Пришлось удалить (ибо была установлена так сказать поверху предыдущей), установить заново, но она по прежнему её не видела. Сделал очистку - удалила.
И вот только после этого программа стала видеть пустую папку в корзине.
По поводу rpm -e --nodeps ничего не добавите?
alex_q_2000, в отличии от Вас я чайник и мало что могу сказать, но видел здесь на форуме - rpm вроде как не совсем родная утилита(всё ли она сделает как надо), а urpmi родная, жаль нет xxblx'а, он точно знает про всё это
поводу rpm -e --nodeps ничего не добавите?
предлагаете оставить пакеты, которым нужны эти псевдосироты без требуемых зависимостей?
как поведет себя пакет, которому нужна была эта псевдосирота после удаления псевдосироты?
или я чего-то не понимаю в логике данного действия, кроме исключения опасности снести полсистемы?
rpm вроде как не совсем родная утилита
rpm как раз родная... вопрос в том, что надо потом будет чинить сломанные зависимости, если снесенная сирота окажется не настоящей сиротой.
alex_q_2000, команда rpm -e --nodeps удаляет пакет без контроля зависимостей (так я в инете прочёл), но чем было плохо проверять зависимости командами(ведь в программе есть кнопка проверки):
левое окно - Требуются для пакета: urpmq --requires-recursive package
правое окно - Сам пакет требуется для: urpmq --whatrequires package
или установленные в системе (что ещё лучше): for i in $(urpmq --whatrequires sudo); do rpm -q $i; done
Вот мой конкретный пример: система говорит что пакет cifs-utils сирота, проверяю Вашей программой(что быстрее, чем ввод команд и названия пакетов) и оказывается, что пакет нужен для samba-client
Вывод такой, если пакет не сирота, то помечу его не сирота и далее он будет жить в системе даже если не будет нужен. Но место он занимает ничтожно мало, пусть живёт, вдруг потребуется. Но могу и не помечать(будет мозолить глаза), подожду когда станет сиротой. В моём примере samba-client неудаляем(так он помечен в пакетном менеджере), значит и cifs-utils не сирота
Второй вариант - если после проверки программой, пакет всё же окажется сиротой, удалю его, а при необходимости другому пакету - пакетный менеджер его запросит для установки заново, всего и делов
Так что предыдущий вариант вполне хорош, в смысле - пусть решает пользователь, а не программа автоматом. Или я что-то не так понял?
Так что предыдущий вариант вполне хорош, в смысле - пусть решает пользователь, а не программа автоматом.
Ну вот и круг замкнулся, разработчики в МСС данный путь с самого начала предлагали. Удаление сирот никакой пользы для системы не несет. Если уж понадобилось срочно дисковое пространство, то не проще ли удалить пакет-тяжеловес, риска грохнуть систему нет.
Mageia Russian Community Forum → Программирование → SNAPPY-CLEANER [очистка системы]
Работает на PunBB, при поддержке Informer Technologies, Inc, при поддержке sevo44.ru