[devel] changelogs for apt repo

[devel] changelogs for apt repo

[@ 2008-05-17 5:34 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 9:50 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 12:06 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 13:23 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 13:54 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 19:00 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 19:55 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 20:01 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 20:50 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 21:09 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[@ 2008-05-17 21:16 UTC (permalink / raw)]

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

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

On Sun, May 18, 2008 at 01:58:11AM +0400, Alexey Gladkov wrote:
> Может пойти по другому пути и разбить этот файл. Чтобы трафик между 
> сервером и обновляемым клиентом была меньше.
В дебиане давно уже диффы пересылаются, привет.


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

А не то что correctly - не correctly.
		-- wrar in sisyphus@

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

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Alexey Tourbin wrote:
> Но там уже есть description (а не только summary).  Так что для чего
> предназначен pkglist это вопрос неоднозначный.

Эта информация нужна для поиска.

> В pkglist вообще-то
> просто копируются хедеры (и их можно читать прямо в цикле через
> headerRead), но при копировании хедеры основательно урезаются,
> исключительно с целью экономии места.

Это я знаю :)
Вот именно. Их урезают и делают как можно меньше чтобы не перегружать 
пользовательскую машину информацией о всём репозитории.

> Какая плата тебя бы устроила?  Думаю что плату можно будет немного
> уменьшить, если сначала отсортировать пакеты по %{SOURCERPM}, а уже
> потом выгонять хедеры.  Тогда bzip2 лучше сожмёт одинаковые changelog'и
> подряд идущих подпакетов.

Может пойти по другому пути и разбить этот файл. Чтобы трафик между 
сервером и обновляемым клиентом была меньше. Ведь, как ты правильно 
сказал, pkglist это сваленные в одну кучу хэдеры (плюс они ещё 
пожаты). Если переделать алгоритм чтобы хэдеры передавались по 
одиночке, а на стороне клиента объединялись, то скачиваться будут 
только новые и изменённые хэдеры.

Сейчас меня несколько волнует, что при обновлении к тебе на машину 
копируются хэдеры от *всех* пакетов в сизифе вне зависимости 
изменились они или нет.

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

Но сизиф-то будет с этой информацией. И поэтому у всех наших клиентов 
ты увеличишь размер pkglist.

> Есть такая дилемма.

Так может написать такую поддержку в apt и перейти на них. В этих 
базах есть всё что может понадобиться. Это тоже хэдеры плюс индексы.

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

И за сколько будем хранить, за год? Через какой период по вашему люди 
обновляются сидя на сизифе (ведь именно этот период тебе и нужно 
охватить с таким подходом) ?

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

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

On Sun, May 18, 2008 at 02:14:34AM +0400, Alexey Gladkov wrote:
>> В дебиане давно уже диффы пересылаются, привет.
> Очень за них рад, но у нас нет диффов, привет.
Ну так может в этом направлении и думать?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> >огласить весь список rpm -qa | grep ^kde? :)
> >3.2.3, Sisyphus (20040804)
> Ничче не понимаю. У меня вроде то же самое (см. выше). Будем Зерга звать?
пора.

Зееерггггг!!!!!?
		-- shrek in sisyphus@

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

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

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

On Sun, May 18, 2008 at 02:21:39AM +0400, Alexey Gladkov wrote:
> Хотите попробовать прикрутить поддержку диффов?
Ох.
Почему-то кажется, что не хочу.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> kak otpisatsa ot etoi rassulki? =)
Отписка происходит автоматически по итогам месяца.
		-- lav in community@

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

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Andrey Rahmatullin wrote:
> В дебиане давно уже диффы пересылаются, привет.

Очень за них рад, но у нас нет диффов, привет.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Andrey Rahmatullin wrote:
> Ну так может в этом направлении и думать?

Разумеется. С ростом репозитория служебной информации будет всё 
больше. Плюс Алексей способствует её увеличению :)

Хотите попробовать прикрутить поддержку диффов?

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Andrey Rahmatullin wrote:
> Ох.
> Почему-то кажется, что не хочу.

Вот именно потому что все так отвечают у нас нет диффов в apt.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Gladkov <legion-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > Alexey Tourbin wrote:
 >> Но там уже есть description (а не только summary).  Так что для чего
 >> предназначен pkglist это вопрос неоднозначный.

 > Эта информация нужна для поиска.

 >> В pkglist вообще-то
 >> просто копируются хедеры (и их можно читать прямо в цикле через
 >> headerRead), но при копировании хедеры основательно урезаются,
 >> исключительно с целью экономии места.

 > Это я знаю :)
 > Вот именно. Их урезают и делают как можно меньше чтобы не перегружать
 > пользовательскую машину информацией о всём репозитории.

 >> Какая плата тебя бы устроила?  Думаю что плату можно будет немного
 >> уменьшить, если сначала отсортировать пакеты по %{SOURCERPM}, а уже
 >> потом выгонять хедеры.  Тогда bzip2 лучше сожмёт одинаковые changelog'и
 >> подряд идущих подпакетов.

 > Может пойти по другому пути и разбить этот файл. Чтобы трафик между
 > сервером и обновляемым клиентом была меньше. Ведь, как ты правильно
 > сказал, pkglist это сваленные в одну кучу хэдеры (плюс они ещё
 > пожаты). Если переделать алгоритм чтобы хэдеры передавались по
 > одиночке, а на стороне клиента объединялись, то скачиваться будут
 > только новые и изменённые хэдеры.

Либо разбить на два:
первый -- старый минус дескрипшны, второй -- дополнительный,
с дескрипшнами и полным чейнджлогом.
Качать ли второй -- скажем, опцией в apt.conf.

-- 

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

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

On Sun, May 18, 2008 at 01:58:11AM +0400, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> >Но там уже есть description (а не только summary).  
> >Так что для чего
> >предназначен pkglist это вопрос 
> >неоднозначный.
> 
> Эта информация нужна для поиска.

Значит, предназначение pkglist двоякое: как текстовая информация
для чтения человеком (и поиска), так и информация для установки
пакетов и автоматического разрешения зависимостей.

> >Какая плата тебя бы устроила?  Думаю что 
> >плату можно будет немного
> >уменьшить, если сначала отсортировать 
> >пакеты по %{SOURCERPM}, а уже
> >потом выгонять хедеры.  Тогда bzip2 лучше 
> >сожмёт одинаковые changelog'и
> >подряд идущих подпакетов.
> 
> Может пойти по другому пути и разбить 
> этот файл. Чтобы трафик между сервером и 
> обновляемым клиентом была меньше. Ведь, 
> как ты правильно сказал, pkglist это 
> сваленные в одну кучу хэдеры (плюс они 
> ещё пожаты). Если переделать алгоритм 
> чтобы хэдеры передавались по одиночке, а 
> на стороне клиента объединялись, то 
> скачиваться будут только новые и 
> изменённые хэдеры.

Если класть хедеры в отдельные файлы, то оверхед в связи с этим
будет очень большой (это и inode'ы, и перекачка информации о файлах).
На самом деле если pkglist не сжимать, то rsync прокачает его гораздо
быстрее (особенно если отсортировать хедеры по %{SOURCERPM}).  Средний
размер хедера в pkglist 2K, если сделать rsync --block-size=1K то мы
возьмём почти чистый diff (с оверхедом того же порядка, что и при
передаче хедеров по отдельности).  Но почему-то почти все используют
ftp, и ради них pkglist бзипют.

> Сейчас меня несколько волнует, что при 
> обновлении к тебе на машину копируются 
> хэдеры от *всех* пакетов в сизифе вне 
> зависимости изменились они или нет.

Это всё-таки не очень большой объем информации (3-4M) по сравнению
с типичным размером dist-upgrade.

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

А также все клиенты смогут читать changelog'и ДО того, как что-то
скачать и обновить (хуже того, apt устроен таким образом, что даже в
промежуток между скачать и обновить довольно-таки неудобно вклиниться --
можно, конечно, сделать apt-get --download-only и потом искать скоченые
*.rpm'ы в /var/*/apt, которые он к тому же манглит...).

В общем, взыскательные клиенты могут и оценить фичу.

> >Есть такая дилемма.
> 
> Так может написать такую поддержку в apt и 
> перейти на них. В этих базах есть всё что 
> может понадобиться. Это тоже хэдеры плюс 
> индексы.

apt всё равно создаёт свой собственный pkgcache.bin, который он mmap'ит
в память, и все его алгоритмы завязаны на формат этого кеша (который я
плохо понимаю!).

И, собственно, rpmdb как альтернатива pkglist ничего не экономит;
а rpmdb как дополнение к pkglist порождает вопросы, напр. должна ли
эта rpmdb скачиваться при apt-get update или нет.  Или у неё статус
такой же как у contents_index.  Типа кто-то его туда наклал.

> >Но ведь мы можем обновляться не с 
> >предпоследней версии на последнюю,
> >а с ещё более ранней.  То есть мы можем 
> >пропустить промежуточное важное
> >изменение.  Поэтому есть наибольший 
> >смысл сохранять changelog'и строго
> >по известной дате, как я и предлагаю 
> >сделать.
> 
> И за сколько будем хранить, за год? Через 
> какой период по вашему люди обновляются 
> сидя на сизифе (ведь именно этот период 
> тебе и нужно охватить с таким подходом) ?

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

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

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

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

On Sat, May 17, 2008 at 09:34:27AM +0400, Alexey Tourbin wrote:
> Теперь остаётся выяснить, сколько это занимает места.
> 
> Обычная генерация сизифа:
> 
> $ cp -prs /ALT/Sisyphus/x86_64 /ALT/Sisyphus/noarch .
> $ rm -f x86_64/base/* noarch/base/*
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD x86_64
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD noarch
> $ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2 
> 2421    x86_64/base/pkglist.classic.bz2
> 1049    noarch/base/pkglist.classic.bz2
> $ 
> 
> Генерация с опцией --changelog-since=2007-01-01:
> 
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 x86_64
> $ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 noarch
> $ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
> 3536    x86_64/base/pkglist.classic.bz2
> 1302    noarch/base/pkglist.classic.bz2
> $ 
> 
> Таким образом, размер скачиваемого при 'apt-get update' заметно
> увеличивается (примерно на треть).  Я считаю это приемлемой платой
> за удовольствие просмотреть changelog пакета ДО скачивания и установки.

On Sat, May 17, 2008 at 11:00:34PM +0400, Alexey Tourbin wrote:
> Какая плата тебя бы устроила?  Думаю что плату можно будет немного
> уменьшить, если сначала отсортировать пакеты по %{SOURCERPM}, а уже
> потом выгонять хедеры.  Тогда bzip2 лучше сожмёт одинаковые changelog'и
> подряд идущих подпакетов.

Я сделал предварительную реализацию сортировки по %{SOURCERPM}.
Результаты теперь такие:

$ PATH=$PWD:$PATH genbasedir --topdir=$PWD x86_64
$ PATH=$PWD:$PATH genbasedir --topdir=$PWD noarch
$ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
2384    x86_64/base/pkglist.classic.bz2
1048    noarch/base/pkglist.classic.bz2
$

$ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 x86_64
$ PATH=$PWD:$PATH genbasedir --topdir=$PWD --changelog-since=2007-01-01 noarch
$ du -bk x86_64/base/pkglist.classic.bz2 noarch/base/pkglist.classic.bz2
3306    x86_64/base/pkglist.classic.bz2
1300    noarch/base/pkglist.classic.bz2
$

Из этого видно следующее: для noarch пакетов переупорядочивание
по %{SOURCERPM} почти ничего не дает.  Это связано с тем, что noarch
пакеты реже распиливают, а при распиливании названия подпакетов реже
отличаются по префиксу (то есть глобального переупорядочивания, которое
может повысить степень сжатия, как напр. в случае с lib%name и %name,
не происходит).

Для x86_64 экономия заметна даже без генерации changelog'ов (2421/2384 =
1.6%, за счёт лучшего совпадения других атрибутов подпакетов),
а особенно с changelog'ом (3536/3306 = 7%, за счёт лучшего сжатия
одинаковых changelog'ов подряд идущих подпакетов).

В принципе выгаданные несколько процентов позволяют мне с большей
уверенностью говорить о включении changelog'ов в репозитарий, хотя
общая картина остаётся скорее прежней: если включить changelog'и по
предложенной схеме, то размер скачиваемого при 'apt-get update'
увеличивается примерно на треть.

Вот патч на genpkglist.cc, я его плохо проверил, но вроде работает.
У меня уже патч на патче сидит и я пока не знаю как его лучше приложить
к тому что есть.

--- apt-0.5.15lorg2/tools/genpkglist.cc-	2008-05-18 00:48:01 +0400
+++ apt-0.5.15lorg2/tools/genpkglist.cc	2008-05-18 05:14:06 +0400
@@ -320,7 +320,7 @@ done:
 }
 
 bool copyFields(Header h, Header newHeader,
-		FILE *idxfile, const char *directory, char *filename,
+		FILE *idxfile, const char *directory, const char *filename,
 		unsigned filesize, map<string,UpdateInfo> &updateInfo,
 		bool fullFileList)
 {
@@ -460,99 +460,34 @@ void usage()
    cerr << "                 one preceding entry (if available)" <<endl;
 }
 
-
-
-#ifndef HAVE_SCANDIR
-// from glibc 1.09.1  mod'd by jmik, ins'd by asm, fix'd by sbi
-int alphasort(const void * a, const void * b)
+static void progress(int cur, int total)
 {
-  return strcmp ((*(struct dirent **) a)->d_name,
-                 (*(struct dirent **) b)->d_name);
+   if (cur > 1)
+      printf("\b\b\b\b\b\b\b\b\b\b");
+   printf(" %04i/%04i", cur, total);
+   fflush(stdout);
 }
 
-int scandir(const char * dir, struct dirent *** namelist, 
-        int (* select)(struct dirent *), 
-        int (* cmp)(const void *, const void *))
+struct rpmfile {
+   const char *basename;
+   const char *sourcerpm;
+};
 
+static
+int rpmfilecmp(const void *a, const void *b)
 {
-  DIR *dp = opendir (dir);
-  struct dirent **v = NULL;
-  size_t vsize = 0, i;
-  struct dirent *d;
-  int save;
-
-  if (dp == NULL)
-    return -1;
-
-  save = errno;
-  errno = 0;
-
-  i = 0;
-  while ((d = readdir (dp)) != NULL)
-    {
-    if (select == NULL || (*select) (d))
-      {
-        if (i == vsize)
-          {
-            struct dirent **newv;
-            if (vsize == 0)
-              vsize = 10;
-            else
-              vsize *= 2;
-            newv = (struct dirent **) realloc (v, vsize * sizeof (*v));
-            if (newv == NULL)
-              {
-              lose:
-                errno = ENOMEM;
-                break;
-              }
-            v = newv;
-          }
-
-        v[i] = (struct dirent *) malloc (d->d_reclen);
-        if (v[i] == NULL)
-          goto lose;
-
-        // *v[i++] = *d;
-	memcpy(v[i], d, d->d_reclen);
-	i++;
-      }
-    }
-
-  v[i] = NULL;
-
-  if (errno != 0)
-    {
-      save = errno;
-      (void) closedir (dp);
-      while (i > 0)
-        free (v[--i]);
-      free (v);
-      errno = save;
-      return -1;
-    }
-
-  (void) closedir (dp);
-  errno = save;
-
-  /* Sort the list if we have a comparison function to sort with.  */
-  if (cmp != NULL)
-    qsort (v, i, sizeof (struct dirent *), cmp);
-
-  *namelist = v;
-  return i;
+   const struct rpmfile *A = (struct rpmfile *)a;
+   const struct rpmfile *B = (struct rpmfile *)b;
+   int cmp = strcmp(A->sourcerpm, B->sourcerpm);
+   if (cmp)
+      return cmp;
+   return strcmp(A->basename, B->basename);
 }
-// end of new stuff from glibc
-#endif /* !HAVE_SCANDIR */
-
 
 int main(int argc, char ** argv) 
 {
    string rpmsdir;
    string pkglist_path;
-   FD_t outfd, fd;
-   struct dirent **dirEntries;
-   int entry_no, entry_cur;
    map<string,UpdateInfo> updateInfo;
    CachedMD5 *md5cache;
    char *op_dir;
@@ -561,13 +496,13 @@ int main(int argc, char ** argv) 
    char *op_update = NULL;
    long /* time_t */ changelog_since = 0;
    FILE *idxfile;
-   int i;
    bool fullFileList = false;
    bool progressBar = false;
    const char *pkgListSuffix = NULL;
    bool pkgListAppend = false;
    
    setlocale(LC_ALL, "C");
+   int i;
    for (i = 1; i < argc; i++) {
       if (strcmp(argv[i], "--index") == 0) {
 	 i++;
@@ -674,14 +609,16 @@ int main(int argc, char ** argv) 
 
    string dirtag = "RPMS." + string(op_suf);
 
-   entry_no = scandir(rpmsdir.c_str(), &dirEntries, selectDirent, alphasort);
-   if (entry_no < 0) {
-      cerr << "genpkglist: error opening directory " << rpmsdir << ":"
-	  << strerror(errno);
-      return 1;
+   if (chdir(rpmsdir.c_str())) {
+      perror(rpmsdir.c_str());
+      exit(1);
+   }
+
+   glob_t gl;
+   if (glob("*.rpm", 0, NULL, &gl)) {
+      cerr << rpmsdir << "/" << "*.rpm: glob failed" <<endl;
+      exit(1);
    }
-   
-   chdir(rpmsdir.c_str());
    
    if (pkgListSuffix != NULL)
 	   pkglist_path = pkglist_path + "/base/pkglist." + pkgListSuffix;
@@ -689,6 +626,7 @@ int main(int argc, char ** argv) 
 	   pkglist_path = pkglist_path + "/base/pkglist." + op_suf;
    
    
+   FD_t outfd;
    if (pkgListAppend == true && FileExists(pkglist_path)) {
       outfd = fdOpen(pkglist_path.c_str(), O_WRONLY|O_APPEND, 0644);
    } else {
@@ -711,30 +649,54 @@ int main(int argc, char ** argv) 
    int isSource;
 #endif   
 
-   if (!fullFileList) {
-      // ALT: file list cannot be stripped in a dumb manner -- this is going
-      // to produce unmet dependencies.  First pass is required to initialize
-      // certain data structures.
-      for (entry_cur = 0; entry_cur < entry_no; entry_cur++) {
-         if (progressBar) {
-            if (entry_cur)
-               printf("\b\b\b\b\b\b\b\b\b\b");
-            printf(" %04i/%04i", entry_cur + 1, entry_no);
-            fflush(stdout);
-         }
+   struct rpmfile *rpms = new struct rpmfile[gl.gl_pathc];
+   int ix, n = 0;
+
+   for (ix = 0; ix < gl.gl_pathc; ix++) {
+         if (progressBar)
+	    progress(ix+1, gl.gl_pathc);
+	 
+	 const char *basename = gl.gl_pathv[ix];
+         FD_t fd = Fopen(basename, "r");
+         if (!fd) {
+	    cerr << "Warning: " << basename << ": " << strerror(errno) <<endl;
+	    continue;
+	 }
 
-         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) {
+         if (rc == RPMRC_OK || rc == RPMRC_NOTTRUSTED || rc == RPMRC_NOKEY)
 #else
          rc = rpmReadPackageHeader(fd, &h, &isSource, NULL, NULL);
-         if (rc == 0) {
+         if (rc == 0)
 #endif
+	 {
+	    ; // good
+	 }
+	 else {
+	    cerr << "Warning: " << basename << ": cannot read package header" <<endl;
+	    continue;
+	 }
+	 
+	 const char *sourcerpm;
+	 rc = headerGetEntry(h, RPMTAG_SOURCERPM, NULL, (void**)&sourcerpm, NULL);
+	 if (!(rc == 1)) {
+	    cerr << "Warning: " << basename << ": no SOURCERPM tag" <<endl;
+	    continue;
+	 }
+
+	 sourcerpm = strdup(sourcerpm);
+	 assert(sourcerpm);
+	 rpms[n].basename = basename;
+	 rpms[n].sourcerpm = sourcerpm;
+	 n++;
+	 
+      // ALT: file list cannot be stripped in a dumb manner -- this is going
+      // to produce unmet dependencies.  First pass is required to initialize
+      // certain data structures.
+	 if (!fullFileList) {
             // path-like Requires
             int_32 reqtype = 0;
             const char **requires = NULL;
@@ -776,37 +738,35 @@ int main(int argc, char ** argv) 
             headerFreeTag(h, dn, (rpmTagType)dnt);
             headerFreeTag(h, di, (rpmTagType)dit);
             
-            headerFree(h);
          }
+	 headerFree(h);
          Fclose(fd);
-      }
    }
-   for (entry_cur = 0; entry_cur < entry_no; entry_cur++) {
+
+   qsort(rpms, n, sizeof(struct rpmfile), rpmfilecmp);
+
+   for (ix = 0; ix < n; ix++) {
       struct stat sb;
 
-      if (progressBar) {
-         if (entry_cur)
-            printf("\b\b\b\b\b\b\b\b\b\b");
-         printf(" %04i/%04i", entry_cur + 1, entry_no);
-         fflush(stdout);
-      }
+      if (progressBar)
+	 progress(ix+1, n);
 
-      if (stat(dirEntries[entry_cur]->d_name, &sb) < 0) {
-	    cerr << "\nWarning: " << strerror(errno) << ": " << 
-		    dirEntries[entry_cur]->d_name << endl;
-	    continue;
+      const char *basename = rpms[ix].basename;
+
+      if (stat(basename, &sb) < 0) {
+	    cerr << "Fatal: " << basename << ": " << strerror(errno) <<endl;
+	    exit(1);
       }
 
       {
 	 Header h;
 	 int rc;
 	 
-	 fd = fdOpen(dirEntries[entry_cur]->d_name, O_RDONLY, 0666);
+	 FD_t fd = Fopen(basename, "r");
 
 	 if (!fd) {
-	    cerr << "\nWarning: " << strerror(errno) << ": " << 
-		    dirEntries[entry_cur]->d_name << endl;
-	    continue;
+	    cerr << "Fatal: " << basename << ": " << strerror(errno) <<endl;
+	    exit(1);
 	 }
 	 
 #if RPM_VERSION >= 0x040100
@@ -822,14 +782,13 @@ int main(int argc, char ** argv) 
 	    newHeader = headerNew();
 	    
 	    copyFields(h, newHeader, idxfile, dirtag.c_str(),
-		       dirEntries[entry_cur]->d_name,
+		       basename,
 		       sb.st_size, updateInfo, fullFileList);
 
 	    if (changelog_since > 0)
 	       copyChangelog(changelog_since, h, newHeader);
 
-	    md5cache->MD5ForFile(string(dirEntries[entry_cur]->d_name), 
-				 sb.st_mtime, md5);
+	    md5cache->MD5ForFile(string(basename), sb.st_mtime, md5);
 	    headerAddEntry(newHeader, CRPMTAG_MD5, RPM_STRING_TYPE, md5, 1);
 
 	    headerWrite(outfd, newHeader, HEADER_MAGIC_YES);
@@ -837,8 +796,8 @@ int main(int argc, char ** argv) 
 	    headerFree(newHeader);
 	    headerFree(h);
 	 } else {
-	    cerr << "\nWarning: Skipping malformed RPM: " << 
-		    dirEntries[entry_cur]->d_name << endl;
+	    cerr << "Fatal: " << basename << ": cannot read package header" <<endl;
+	    exit(1);
 	 }
 	 Fclose(fd);
       }

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

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

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

On Sun, May 18, 2008 at 06:07:51AM +0400, Alexey Tourbin wrote:
> В принципе выгаданные несколько процентов позволяют мне с большей
> уверенностью говорить о включении changelog'ов в репозитарий, хотя
> общая картина остаётся скорее прежней: если включить changelog'и по
> предложенной схеме, то размер скачиваемого при 'apt-get update'
> увеличивается примерно на треть.

В абсолютных цифрах это примерно 3.5M -> 4.5M.

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

Re: [devel] changelogs for apt repo

[Kirill Maslinsky]

On Sun, May 18, 2008 at 03:09:39AM +0600, Andrey Rahmatullin wrote:
> On Sun, May 18, 2008 at 12:16:21AM +0300, Led wrote:
> > Вменяемый Summary - достаточно.
> Наивно enough.
> 
> > > Плюсм apt-cache search особого смысла не имеет без дескрипшенов.
> > См. выше. Но яопять же - это ИМХО.
> А это просто бред.
> См. многочисленные техники прописывания всякой полезной инфы в дескрипшен
> именно с целью релевантного apt-cache search.
Кстати, тоже неплохо бы оформить в полиси (хотя бы даже HOWTO),
как писать description и summary. А то они не всегда бывают 
информативные.


--
Kirill Maslinsky
ALT Linux Team

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Alexey Tourbin wrote:
> Я сделал предварительную реализацию сортировки по %{SOURCERPM}.
> Результаты теперь такие:

У меня вопрос: изменив сортировку по алфавиту на сортировку по 
%{SOURCERPM} ты не ухудшил скорость поиска `apt-cache search` ?

Не нужно ли ввести корректировку алгоритма поиска (apt-cache search), 
чтобы он искал только в первом changelog'е при условии что поле 
%{SOURCERPM} у нескольких пакетов в pkglist совпадает?

Вообще, очень неприятно что changelog'и дублируются в этой реализации.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

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

On Sun, May 18, 2008 at 01:26:20PM +0400, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> >Я сделал предварительную реализацию 
> >сортировки по %{SOURCERPM}.
> >Результаты теперь такие:
> 
> У меня вопрос: изменив сортировку по 
> алфавиту на сортировку по %{SOURCERPM} ты не 
> ухудшил скорость поиска `apt-cache search` ?

А как могла скорость ухудшиться?  Однако появилась особенность:
в выдаче 'apt-cache search' найденные пакеты отсортированы не по
названию, а по %{SOURCERPM}.

(Старое поведение)
$ apt-cache search apt |awk '$1~/apt\>/'
apt - Debian's Advanced Packaging Tool with RPM support
apt-conf-desktop - A set of apt configuration files for ALT Linux Desktop
apt-conf-server - A set of apt configuration files for ALT Linux Server
apt-conf-sisyphus - A set of apt configuration files for ALT Linux Sisyphus
apt-rsync - rsync method support for APT
apt-utils - Utilities to create APT repositaries (the indices)
capt - CAPT Linux driver
kio-apt - An apt:/ protocol in konqueror
libapt - APT's core libraries
libapt-devel - Development files and documentation for APT's core libs
apt-log - Log support for APT
apt-scripts - Lua scripts for APT
docs-alterator_apt-kirill - Extra packages
docs-packages_apt - Install and remove programs (packages)
$ 

(Новое поведение)
$ ./build/aptbox/apt-cache search apt |awk '$1~/apt\>/'
apt - Debian's Advanced Packaging Tool with RPM support
apt-rsync - rsync method support for APT
apt-utils - Utilities to create APT repositaries (the indices)
libapt - APT's core libraries
libapt-devel - Development files and documentation for APT's core libs
apt-conf-desktop - A set of apt configuration files for ALT Linux Desktop
apt-conf-server - A set of apt configuration files for ALT Linux Server
apt-conf-sisyphus - A set of apt configuration files for ALT Linux Sisyphus
capt - CAPT Linux driver
kio-apt - An apt:/ protocol in konqueror
apt-log - Log support for APT
apt-scripts - Lua scripts for APT
docs-alterator_apt-kirill - Extra packages
docs-packages_apt - Install and remove programs (packages)
$ 

Теперь libapt* "примыкает" к пакетам apt*.  В принципе это изменение
нельзя однозначно квалифицировать как нежелательное или неправильное,
потому что нарушение алфавитного порядка позволяет нам догадаться,
что речь идёт о подпакетах, собранных из одного src.rpm пакета
(группировку по src.rpm при поиске можно даже считать интересной фичей,
просто это информация здесь не выражена явно).

К тому же на самом деле сортировка действует только в пределах
репозитария, так что при переходе к noarch пакеты опять начинаются
с буквы "a".

> Не нужно ли ввести корректировку 
> алгоритма поиска (apt-cache search), чтобы он 
> искал только в первом changelog'е при условии 
> что поле %{SOURCERPM} у нескольких пакетов в 
> pkglist совпадает?

Наверное, нужно.  То есть при совпадении по changelog'у следовало
бы игнорировать все последующие (adjacent) пакеты с совпадающим SOURCERPM.
Но я боюсь что жесткая структурная декомпозиция снизу вверх, то есть
поиск идёт per header, и протощить нужную информацию будет сложновато.

Точнее, не знаю, нужно или не нужно.
Я пока ещё не добавил поиск по changelog'ам.

> Вообще, очень неприятно что changelog'и 
> дублируются в этой реализации.

Но если дубли сгруппировать, то они очень хорошо сжимаются.
Если же выносить дублирующуюся информацию в отдельное место,
то, прежде всего, придётся распустить Header как структуру;
а это дополнительный оверхед на bookkeeping + проверка целостности.

Попробуй распустить хедер на два "подхедера", сразу встанет вопрос,
соответствует ли первый подхедер второму или нет.

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

Re: [devel] changelogs for apt repo

[Alexey Gladkov]

Alexey Tourbin wrote:
> А как могла скорость ухудшиться?

Я думал ты добавил changelog в поиск.

> Я пока ещё не добавил поиск по changelog'ам.

Я считаю что и не нужно добавлять. Потому что `apt-cache search` 
предназначен для поиска пакетов, а в случае подключения changelog'ов 
будут находиться пакеты в changelog'е которого содержится ключевое 
слово. Ты приводил пример с CVE, но такой тип поиска намного более 
редок чем обычный поиск пакета по ключевому слову. Если всё-таки 
кому-то хочется искать по ним, то он сможет воспользоваться --full.

-- 
Rgrds, legion

Re: [devel] changelogs for apt repo

[Ildar Mulyukov]

On 18.05.2008 05:03:31, Alexey Tourbin wrote:
> Если класть хедеры в отдельные файлы, то оверхед в связи с этим будет  
> очень большой (это и inode'ы, и перекачка информации о файлах). На  
> самом деле если pkglist не сжимать, то rsync прокачает его гораздо  
> быстрее (особенно если отсортировать хедеры по %{SOURCERPM}).   
> Средний размер хедера в pkglist 2K, если сделать rsync  
> --block-size=1K то мы возьмём почти чистый diff (с оверхедом того же  
> порядка, что и при передаче хедеров по отдельности).  Но почему-то  
> почти все используют ftp, и ради них pkglist бзипют.

	Алексей,

поделитесь, пожалуйста, как настроить apt, чтобы это делать? Или Вы  
имеете в виду напрямую rsync-ом?

С уважением,
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] changelogs for apt repo

[Alexey Tourbin]

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

On Mon, May 19, 2008 at 10:02:03AM +0600, Ildar Mulyukov wrote:
> On 18.05.2008 05:03:31, Alexey Tourbin wrote:
> >Если класть хедеры в отдельные файлы, то 
> >оверхед в связи с этим будет  очень 
> >большой (это и inode'ы, и перекачка 
> >информации о файлах). На  самом деле если 
> >pkglist не сжимать, то rsync прокачает его 
> >гораздо  быстрее (особенно если 
> >отсортировать хедеры по %{SOURCERPM}).   
> >Средний размер хедера в pkglist 2K, если 
> >сделать rsync  --block-size=1K то мы возьмём почти 
> >чистый diff (с оверхедом того же  порядка, 
> >что и при передаче хедеров по 
> >отдельности).  Но почему-то  почти все 
> >используют ftp, и ради них pkglist бзипют.
> 
> 	Алексей,
> 
> поделитесь, пожалуйста, как настроить apt, 
> чтобы это делать? Или Вы  имеете в виду 
> напрямую rsync-ом?

Дело в том, что rsync(1) как раз очень хорошо подохдит для
синхронизации бинарных (и вообще любых) файлов, в которых некоторые
куски меняются (возможно, со смещением), а некоторые куски остаются
без изменения (возможно, тоже со смещением).  Почитайте где-нибудь
статью этого гуру я не помню как его на букву T тоже.  Там очень
хорошо описано, как файл разбивается на маленькие блоки, и на стороне
клиента вычисляются всевозможные хеши для любых смещений.

Поняв это, Вам также станят ясно (как Божий день), что совсем не нужен
ещё один протокол для синхронизации кусков чего-то с другими кусками
ещё чего-то.  Достаточно одного хорошего протокола, коим является rsync.

Проблема только в том, что rsync "не берёт" сжатые файлы.  Это связано
с понятием об этнропии, и это очень долго объяснять.  Суть в том что
сжатие полностью уничтожает буквально совпадение блоков, которое нужно
для rsync.  

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

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

Re: [devel] changelogs for apt repo

[Ildar Mulyukov]

On 19.05.2008 10:53:14, Alexey Tourbin wrote:
> On Mon, May 19, 2008 at 10:02:03AM +0600, Ildar Mulyukov wrote:
> > On 18.05.2008 05:03:31, Alexey Tourbin wrote:
>>> Если класть хедеры в отдельные файлы, то оверхед в связи с этим  
>>> будет  очень большой (это и inode'ы, и перекачка информации о  
>>> файлах). На  самом деле если pkglist не сжимать, то rsync прокачает  
>>> его гораздо  быстрее (особенно если отсортировать хедеры по  
>>> %{SOURCERPM}). Средний размер хедера в pkglist 2K, если сделать  
>>> rsync  --block-size=1K то мы возьмём почти чистый diff (с оверхедом  
>>> того же  порядка, что и при передаче хедеров по отдельности).  Но  
>>> почему-то  почти все используют ftp, и ради них pkglist бзипют.
>> 	Алексей, поделитесь, пожалуйста, как настроить apt, чтобы это  
>> делать? Или Вы  имеете в виду напрямую rsync-ом?
> 
> Дело в том, что rsync(1) как раз очень хорошо подохдит для  
> синхронизации бинарных (и вообще любых) файлов, в которых некоторые  
> куски меняются (возможно, со смещением), а некоторые куски остаются  
> без изменения (возможно, тоже со смещением).  Почитайте где-нибудь  
> статью этого гуру я не помню как его на букву T тоже.  Там очень  
> хорошо описано, как файл разбивается на маленькие блоки, и на стороне  
> клиента вычисляются всевозможные хеши для любых смещений.
> Поняв это, Вам также станят ясно (как Божий день), что совсем не  
> нужен ещё один протокол для синхронизации кусков чего-то с другими  
> кусками ещё чего-то.  Достаточно одного хорошего протокола, коим  
> является rsync.


А! Спасибо. Как работает rsync - я уже немного в курсе.

> Проблема только в том, что rsync "не берёт" сжатые файлы.  Это  
> связано с понятием об этнропии, и это очень долго объяснять.  Суть в  
> том что сжатие полностью уничтожает буквально совпадение блоков,  
> которое нужно для rsync.
> В общем, дилемма простая: либо синхронизируем разжатое, либо полностью
> скачиваем сжатое.

Хотите "трилемму"? Можно ещё впаять поддержку rsync в apt-get update.

Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

On Mon, May 19, 2008 at 04:26:02PM +0600, Ildar Mulyukov wrote:
> Хотите "трилемму"? Можно ещё впаять поддержку rsync в apt-get update.
apt-get install apt-rsync
Не знаю, правда, как он работает.

Re: [devel] changelogs for apt repo

[Pavlov Konstantin]

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

On Mon, May 19, 2008 at 10:35:46AM +0000, Andrey Rahmatullin wrote:
> On Mon, May 19, 2008 at 04:26:02PM +0600, Ildar Mulyukov wrote:
> > Хотите "трилемму"? Можно ещё впаять поддержку rsync в apt-get update.
> apt-get install apt-rsync
> Не знаю, правда, как он работает.

Нормально работает, rsync -- один из apt methods становится.

-- 
[...] любители ругаться не читают документацию :-)
		-- aen in devel@

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

Re: [devel] changelogs for apt repo

[Andrey Rahmatullin]

On Mon, May 19, 2008 at 02:41:07PM +0400, Pavlov Konstantin wrote:
> Нормально работает, rsync -- один из apt methods становится.
Знаю, даже юзал. Я про экономию и прочее.

Re: [devel] changelogs for apt repo

[Aleksey Avdeev]

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

Pavlov Konstantin пишет:
> On Mon, May 19, 2008 at 10:35:46AM +0000, Andrey Rahmatullin wrote:
>> On Mon, May 19, 2008 at 04:26:02PM +0600, Ildar Mulyukov wrote:
>>> Хотите "трилемму"? Можно ещё впаять поддержку rsync в apt-get update.
>> apt-get install apt-rsync
>> Не знаю, правда, как он работает.
> 
> Нормально работает, rsync -- один из apt methods становится.

  Не совсем нормально: по apt-get update каждый раз _полностью_
выкачивает файлы описания репозитария, даже если они не менялись. (Для
ftp -- это не так.)

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [devel] changelogs for apt repo

[Alexey Morozov]

В сообщении от Sunday 18 May 2008 02:00:34 Alexey Tourbin написал(а):

> На самом деле то что через apt нельзя посмотреть изменения в пакете
> это одна из основных претензий к апту.  Александр Боковой ещё
> в х**-знает-каком году писал, как он в Сане показывал наш synaptic,
> и первое что у него саны спросили это где посмотреть изменения
> обновляемых пакетов.

Да, кстати. Но это, кстати, особенность именно [нашего] apt-rpm, у 
дебианоубунтовцев в этом месте всё нормально, там изменения еще и по 
приоритету сортируются, что крайне полезно енд-лузеру, вроде меня, любящего 
красивые окошки и дружелюбные программки.

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

Хотя, конечно, приоритетность изменений, видимо, должна быть более 
комплексной. Что-то типа "характер изменений" (security, bugfix, enhancement, 
или всё вместе) и "величина изменений" (minor, intermediate, major). Только в 
этом случае "величина изменений" - это не просто константа для данного 
пакета, а некоторая кумулятивная характеристика, складывающаяся из характера 
изменений самого пакета и характера изменений сборочного окружения.

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

Re: [devel] changelogs for apt repo

[Alexander Bokovoy]

19.05.08, Alexey Tourbin<at@altlinux.ru> написал(а):
>  Проблема только в том, что rsync "не берёт" сжатые файлы.  Это связано
>  с понятием об этнропии, и это очень долго объяснять.  Суть в том что
>  сжатие полностью уничтожает буквально совпадение блоков, которое нужно
>  для rsync.
На самом деле, если жать gzip --rsyncable, то будут блоки по 100к, что
как раз и помогает rsync. В случае bzip2 блоки будут 900к (--best или
по умолчанию) или кратны 100к (-1, -2 и так далее -- это 100к, 200к,
... до 900к с -9). То есть, если для rsync указать размер блока в
размер блока, с которым сжимались данные при помощи bzip2, то
производительность будет выше, чем без понимания размера блока.


-- 
/ Alexander Bokovoy