From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <000a01c32be2$278ef770$400aa8c0@434ntws> From: "Anton V. Denisov" To: Date: Fri, 6 Jun 2003 16:14:42 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Return-Path: fire@kgpu.kamchatka.ru X-MDaemon-Deliver-To: devel@altlinux.ru Subject: [devel] [URGENT] IQ: unowned dirs in /usr/lib Sender: devel-admin@altlinux.ru Errors-To: devel-admin@altlinux.ru X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: Приветствую всех. Решил тут почистить систему, поскольку сейчас это Мастер 2.2, который в своё время был Спринг 2001. Среди прочих мер выполнил от суперпользователя команду find /usr/lib -type d -exec rpmquery -f {} 2>&1 \; |grep owned и результаты меня несколько ошеломили. Куча каталогов, у которых нет владельцев, но есть содержимое, владельцами которого являются некоторые пакеты. Например: warning: file /usr/lib/ruby is not owned by any package warning: file /usr/lib/ruby/site_ruby is not owned by any package warning: file /usr/lib/ruby/1.7 is not owned by any package warning: file /usr/lib/ruby/1.7/i586-linux-gnu is not owned by any package warning: file /usr/lib/ruby/vendor_ruby is not owned by any package warning: file /usr/lib/perl5/vendor_perl/i386-linux/auto/Term is not owned by any package warning: file /usr/lib/perl5/vendor_perl/i386-linux/Term is not owned by any package warning: file /usr/lib/perl5/vendor_perl/SGMLS is not owned by any package warning: file /usr/lib/consolehelper is not owned by any package warning: file /usr/lib/imlib2 is not owned by any package warning: file /usr/lib/imlib2/loaders is not owned by any package warning: file /usr/lib/imlib2/loaders/filter is not owned by any package warning: file /usr/lib/imlib2/loaders/image is not owned by any package warning: file /usr/lib/kernel is not owned by any package warning: file /usr/lib/ghostscript/7.05 is not owned by any package warning: file /usr/lib/python2.2/site-packages/pyglade is not owned by any package warning: file /usr/lib/python2.2/site-packages/gnome is not owned by any package И это лишь часть списка. Собственно вопрос: можно ли как-то на уровне rpm или дополнительной проверки в утилите sisyphus избежать "ничейных" файлов и каталогов? Если делать это в rpm, то, наверное, возникнут проблемы с междупакетными зависимостями. Например, пакет libapt владеет каталогом /var/cache/apt, а пакет apt-utils каталогом /var/cache/apt/genpkglist, однако никогда не возникнет ситуации, что каталог /var/cache/apt останется без владельца, поскольку нельзя удалить libapt, не удаляя apt-utils - здесь и проявляются междупакетные зависимости. А если бы apt-utils и libapt собирались из разных SRPM, то нельзя бы было отловить "ничейность" /var/cache/apt на стадии сборки apt-utils. Наверное, APT и что-то типа BTE могут помочь - проверяем, кто предоставляет каталог в дистрибутиве и смотрим, есть ли у пакета, который что-то хранит в этом каталоге, зависимость на этот пакет. Хотя provides/whatprovides в APT ещё не реализованы :-( Везде засада. Кстати, в голову пришла идея о новом checker для osec, который бы рапортовал обо всех объектах, которых нет в базе RPM. Но много минусов у этого решения. "Ничейные" объекты есть грубое нарушение ALT Secure Packaging Policy, поэтому надо как-то решить эту проблему. Особо остро эта проблема стоит при частых апдейтах пакетов - в системе остаётся много таких пустых "ничейных" каталогов и файлов. Особая "помойка" наблюдается в /usr/{X11R6,include,lib,share}. В /var тоже насчиталось 64 "ничейных" каталога, даже без тех, что в postfix'овском chroot'е. Даже /usr/share/locale и его подкаталоги никому не принадлежат! P.S. Если провести эксперимент - установить с нуля Мастер 2.2, а затем поискать "ничейные" файлы и каталоги, то результат будет плачевным. Получается наполовину package based distro. К сожалению. С уважением, Антон В. Денисов.