[devel] symlinks.req: semi-unmets

[devel] symlinks.req: semi-unmets

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]

On Mon, Aug 06, 2007 at 03:08:04PM +0400, Alexey Tourbin wrote:
> On Sat, Aug 04, 2007 at 01:41:56AM +0400, Dmitry V. Levin wrote:
> > Свою долю критики за неожиданные зависимости ты ещё получишь, не стоит
> > беспокоиться.
> 
> Кстати, только что обнаружил пример необходимости symlinks.req.
[...]
> То есть не хватает зависимости на consolehelper.  Правда, не факт
> что symlinks.req сможет проставить именно зависимость на
> consolehelper, т.к. find-package работает по очень урезанному
> contents_index.  В худшем случае появится "полу-unmet" на
> /usr/lib/consolehelper/helper.

Вот что теперь вылезает на openssl:

$ rpm -qpR libssl6-0.9.8d-alt3.athlon.rpm |grep /usr/share/
/usr/share/ca-certificates/ca-bundle.crt  
$ rpm -qlvp libssl6-0.9.8d-alt3.athlon.rpm |grep /usr/share/ca-
lrwxrwxrwx    1 root    root               48 Aug  7 01:42 /var/lib/ssl/cert.pem -> ../../../usr/share/ca-certificates/ca-bundle.crt
$

Это тот самый symlinks.req, которые добавляет зависимости на битые
симлинки.

The following packages have unmet dependencies:
  libssl6: Depends: /usr/share/ca-certificates/ca-bundle.crt but it is not installable


ЗАОСТРЯЮ ПРОБЛЕМУ "ПОЛУ-АНМЕТОВ".


Это проблема проявляется тогда, когда зависимость имеет вид /ПУТЬ,
но у соответствующего пакета не стоит Provides: /ПУТЬ.  На уровне
rpm это не является unmet'ом: если при установке пакета с такой
зависимостью имеется какой-либо другой пакет с файлом /ПУТЬ,
то для rpm это "канает".

С другой стороны, apt видит такую зависимость именно как unmet.
Вообще-то у апта к каждому пакету есть файловые листы, и он использует
их для разрешения такого рода зависимостей.  Но при изготовлении
репозитария аптовые листы у нас насильно "оптимизируются".

Два простых варианта решения это проблемы:

1) Генерировать более полный content_index для hasher, чтобы любой путь
более гарантированно трансформировался в название пакета (насколько
более полный/гарантированно?).

2) Восстановить файловые листы для апт.  Насколько потяжелеет
pkglist.classic.bz2?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] symlinks.req: semi-unmets

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

On Tue, Aug 07, 2007 at 02:20:48AM +0400, Alexey Tourbin wrote:
> ЗАОСТРЯЮ ПРОБЛЕМУ "ПОЛУ-АНМЕТОВ".
> 
> 
> Это проблема проявляется тогда, когда зависимость имеет вид /ПУТЬ,
> но у соответствующего пакета не стоит Provides: /ПУТЬ.  На уровне
> rpm это не является unmet'ом: если при установке пакета с такой
> зависимостью имеется какой-либо другой пакет с файлом /ПУТЬ,
> то для rpm это "канает".
> 
> С другой стороны, apt видит такую зависимость именно как unmet.
> Вообще-то у апта к каждому пакету есть файловые листы, и он использует
> их для разрешения такого рода зависимостей.  Но при изготовлении
> репозитария аптовые листы у нас насильно "оптимизируются".
> 
> Два простых варианта решения это проблемы:
> 
> 1) Генерировать более полный content_index для hasher, чтобы любой путь
> более гарантированно трансформировался в название пакета (насколько
> более полный/гарантированно?).
> 
> 2) Восстановить файловые листы для апт.  Насколько потяжелеет
> pkglist.classic.bz2?

Если мыслей нет, то утро вечера мудренее.  Пока есть только идея
захачить hsh-sh-cache-contents-functions, чтобы он изготовлял
contents_index_all.gz.

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

$ grep /sbin/ifup build/cache/contents/contents_index_bin 
/sbin/ifup      etcnet
/sbin/ifup      net-scripts
$

Это потому что net-scripts из i586 а etcnet из noarch.

--- /usr/bin/hsh-sh-cache-contents-functions-	2007-06-16 13:11:39 +0000
+++ /usr/bin/hsh-sh-cache-contents-functions	2007-08-06 23:29:22 +0000
@@ -195,6 +195,8 @@ create_contents()
 		Fatal 'Failed to create contents index.'
 	fi
 
+	sort -u -o "$contents" "$contents"
+
 	if ! LC_COLLATE=C prepare_contents "$tmpdir" >"$contents_index_bin"; then
 		rm -rf "$tmpdir"
 		Fatal 'Failed to prepare contents index.'

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] symlinks.req: semi-unmets

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]

On Tue, Aug 07, 2007 at 03:34:49AM +0400, Alexey Tourbin wrote:
> On Tue, Aug 07, 2007 at 02:20:48AM +0400, Alexey Tourbin wrote:
> > ЗАОСТРЯЮ ПРОБЛЕМУ "ПОЛУ-АНМЕТОВ".
> > 
> > 
> > Это проблема проявляется тогда, когда зависимость имеет вид /ПУТЬ,
> > но у соответствующего пакета не стоит Provides: /ПУТЬ.  На уровне
> > rpm это не является unmet'ом: если при установке пакета с такой
> > зависимостью имеется какой-либо другой пакет с файлом /ПУТЬ,
> > то для rpm это "канает".
> > 
> > С другой стороны, apt видит такую зависимость именно как unmet.
> > Вообще-то у апта к каждому пакету есть файловые листы, и он использует
> > их для разрешения такого рода зависимостей.  Но при изготовлении
> > репозитария аптовые листы у нас насильно "оптимизируются".
> > 
> > Два простых варианта решения это проблемы:
> > 
> > 1) Генерировать более полный content_index для hasher, чтобы любой путь
> > более гарантированно трансформировался в название пакета (насколько
> > более полный/гарантированно?).
> > 
> > 2) Восстановить файловые листы для апт.  Насколько потяжелеет
> > pkglist.classic.bz2?
> 
> Если мыслей нет, то утро вечера мудренее.  Пока есть только идея
> захачить hsh-sh-cache-contents-functions, чтобы он изготовлял
> contents_index_all.gz.

Предварительная реализация и тестирование contents_index_all.gz
выявило вот какую проблему.  При сборке startup:

shell.req: /usr/src/tmp/startup-buildroot/etc/rc.d/init.d/clock: checking contents_index_all for /etc/init.d/functions
shell.req: /usr/src/tmp/startup-buildroot/etc/rc.d/init.d/clock: /etc/init.d/functions -> service (via rpmdb)

Здесь проблема в том, что вместо ". /etc/rc.d/init.d/functions" там
используется ". /etc/init.d/functions", и поиск сначала обламывается
по contens_index_bin, потому что "нельзя понять", что /etc/init.d
это симлинк на /etc/rc.d/init.d.  Потом, соответственно, запускается
"дорогой" поиск по contents_index_all, и опять обламывается.  В конечном
счёте происходит fallback на текущий rpmdb, который и дает результат.
Если бы поиск по rpmdb ничего не дал, то получился бы "полу-анмет"
на /etc/init.d/functions.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] symlinks.req: semi-unmets

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 2515 bytes --]

On Tue, Aug 07, 2007 at 02:20:48AM +0400, Alexey Tourbin wrote:
> On Mon, Aug 06, 2007 at 03:08:04PM +0400, Alexey Tourbin wrote:
> ЗАОСТРЯЮ ПРОБЛЕМУ "ПОЛУ-АНМЕТОВ".
> 
> 
> Это проблема проявляется тогда, когда зависимость имеет вид /ПУТЬ,
> но у соответствующего пакета не стоит Provides: /ПУТЬ.  На уровне
> rpm это не является unmet'ом: если при установке пакета с такой
> зависимостью имеется какой-либо другой пакет с файлом /ПУТЬ,
> то для rpm это "канает".
> 
> С другой стороны, apt видит такую зависимость именно как unmet.
> Вообще-то у апта к каждому пакету есть файловые листы, и он использует
> их для разрешения такого рода зависимостей.  Но при изготовлении
> репозитария аптовые листы у нас насильно "оптимизируются".
> 
> Два простых варианта решения это проблемы:
> 
> 1) Генерировать более полный content_index для hasher, чтобы любой путь
> более гарантированно трансформировался в название пакета (насколько
> более полный/гарантированно?).
> 
> 2) Восстановить файловые листы для апт.  Насколько потяжелеет
> pkglist.classic.bz2?

Я немного захачил апт, но это всё равно как следует не работает, см. ниже.

commit 30e27b0f1c74b4f67354a6035fae3e210131bca1
Author: Alexey Tourbin <at@altlinux>
Date:   Sat Aug 11 20:01:05 2007 +0400

    apt-0.5.15lorg2-alt-genpkglist-reqfiles.patch
    
    genpkglist strips file lists by default (without --bloat option).
    It keeps only some "useful files" by using a few ad hoc patterns.
    
    This can break file-level dependencies.  Consider pkgA requires
    /usr/lib/foo1/bar, and pkgB owns this file without explicitly
    providing it.  Now if genpkglist strips /usr/lib/foo1/bar
    from pkgB file list, this is going to be an unmet dependency.
    
    This patch changes genpkglist behaviour, so that, when genpkglist
    is invoked without --bloat option, it first finds all file-level
    dependencies (something like "rpm -qaR |grep ^/").  This requires
    a separate pass.  The list of file-level dependencies is saved into
    "reqfiles" global variable.  And on the second (normal) pass, the
    function usefulFile() is modified to check the "reqfiles" variable;
    that is, it should keep a file in the file list if it's been required
    by some package in the repo.
    
    (Unfortunately, this patch does not solve all of the problems
    I want it to solve; we have separate repos for i586 and noarch --
    inter-repo file-level dependencies cannot be resolved this way.)

[-- Attachment #1.2: apt-0.5.15lorg2-alt-genpkglist-reqfiles.patch --]
[-- Type: text/plain, Size: 3224 bytes --]

--- apt-0.5.15lorg2/tools/genpkglist.cc-	2007-08-11 15:10:54 +0400
+++ apt-0.5.15lorg2/tools/genpkglist.cc	2007-08-11 19:36:03 +0400
@@ -18,6 +18,8 @@
 #include <map>
 #include <iostream>
 
+#include <tr1/unordered_set>
+
 #include <apt-pkg/error.h>
 #include <apt-pkg/tagfile.h>
 #include <apt-pkg/configuration.h>
@@ -77,20 +79,30 @@ typedef struct {
    string url;
 } UpdateInfo;
 
+static std::tr1::unordered_set<std::string> reqfiles;
 
-static inline int usefullFile(char *a)
+static int usefulFile(const char *dir, const char *basename)
 {
-   int l = strlen(a);
-   
-   if (strstr(a, "bin") || strstr(a, "/etc") || strncmp(a, "/lib", 4) == 0)
-       return 1;
-   
-   if (l < 3)
-       return 0;
+   if (strstr(dir, "bin/"))
+      return 1;
+   if (strstr(dir, "/etc/"))
+      return 1;
    
-   if (strcmp(a + l - 3, ".so") == 0
-       || strstr(a, ".so."))
-       return 1;
+   const char *pos = strstr(basename, ".so");
+   if (pos > basename) {
+      int c = pos[3];
+      if (c == '.' || c == '\0')
+         return 1;
+   }
+
+   if (reqfiles.size() > 0) {
+      char fullname[strlen(dir) + strlen(basename) + 1];
+      strcpy(fullname, dir);
+      strcat(fullname, basename);
+      if (reqfiles.find(fullname) != reqfiles.end())
+         return 2;
+   }
+
    return 0;
 }
 
@@ -133,9 +145,8 @@ static void copyStrippedFileList(Header 
    {
       int ok = 0;
       
-      ok = usefullFile(basenames[i]);
-      if (!ok) 
-	  ok = usefullFile(dirnames[dirindexes[i]]);
+      ok = usefulFile(dirnames[dirindexes[i]], basenames[i]);
+      // if (ok > 1) cerr << "useful file: " << dirnames[dirindexes[i]] << basenames[i] <<endl;
       
       if (!ok) {
 	 int k = i;
@@ -599,6 +610,40 @@ int main(int argc, char ** argv) 
    int isSource;
 #endif   
 
+   if (!fullFileList) {
+      // first pass: initialize reqfiles
+      for (entry_cur = 0; entry_cur < entry_no; entry_cur++) {
+         fd = fdOpen(dirEntries[entry_cur]->d_name, O_RDONLY, 0666);
+         if (!fd)
+            continue;
+         int rc;
+         Header h;
+#if RPM_VERSION >= 0x040100
+         rc = rpmReadPackageFile(ts, fd, dirEntries[entry_cur]->d_name, &h);
+         if (rc == RPMRC_OK || rc == RPMRC_NOTTRUSTED || rc == RPMRC_NOKEY) {
+#else
+         rc = rpmReadPackageHeader(fd, &h, &isSource, NULL, NULL);
+         if (rc == 0) {
+#endif
+            int reqtype;
+            const char **requires;
+            int nreq;
+            rc = headerGetEntry(h, RPMTAG_REQUIRENAME, &reqtype, (void**)&requires, &nreq);
+            if (rc == 1 && reqtype == RPM_STRING_ARRAY_TYPE) {
+               int i;
+               for (i = 0; i < nreq; i++) {
+                  const char *req = requires[i];
+                  if (*req == '/') {
+                     // cerr << dirEntries[entry_cur]->d_name << " requires " << req << endl;
+                     reqfiles.insert(req);
+                  }
+               }
+            }
+            headerFree(h);
+         }
+         Fclose(fd);
+      }
+   }
    for (entry_cur = 0; entry_cur < entry_no; entry_cur++) {
       struct stat sb;
 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] symlinks.req: semi-unmets

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On Tue, Aug 07, 2007 at 02:20:48AM +0400, Alexey Tourbin wrote:
> $ rpm -qpR libssl6-0.9.8d-alt3.athlon.rpm |grep /usr/share/
> /usr/share/ca-certificates/ca-bundle.crt  
> $ rpm -qlvp libssl6-0.9.8d-alt3.athlon.rpm |grep /usr/share/ca-
> lrwxrwxrwx    1 root    root               48 Aug  7 01:42 /var/lib/ssl/cert.pem -> ../../../usr/share/ca-certificates/ca-bundle.crt
> $

Захачка genpkglist (apt-utils, см. соседнее письмо) решает проблему
с файловой зависмостью
libssl6 -> /usr/share/ca-certificates/ca-bundle.crt -> ca-certificates
ЕСЛИ пакеты libssl6 и ca-certificates находятся в одном репозитарии
(например, как в RPMS.hasher).  Но в сизифе они находятся в РАЗНЫХ
репозитариях (соотв. i586 и noarch).  Поэтому захачка genpkglist в
данном случае ничего не даст.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] symlinks.req: semi-unmets

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

Мои письма в devel приходят с задержкой.

Received: from master.altlinux.org (master.altlinux.org [62.118.250.235])
        by lists.altlinux.org (Postfix) with ESMTP id BB5EA5963202
        for <devel@lists.altlinux>; Mon, 13 Aug 2007 12:24:18 +0400 (MSD)
Received: from solemn.turbinal (localhost.localdomain [127.0.0.1])
        by master.altlinux.org (Postfix) with ESMTP id 01A95E41E4
        for <devel@lists.altlinux>; Sat, 11 Aug 2007 23:07:19 +0400 (MSD)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]