From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.2.3 Date: Thu, 31 Jan 2008 18:38:15 +0200 From: Igor Vlasenko To: ALT Linux Team development discussions Message-ID: <20080131163815.GA30266@dad.imath.kiev.ua> References: <20080120191929.GF24211@solemn.turbinal> <20080120215428.GO24211@solemn.turbinal> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080120215428.GO24211@solemn.turbinal> User-Agent: Mutt/1.5.17 (2007-11-01) Received-SPF: pass (dad.imath.kiev.ua: domain of vlasenko@dad.imath.kiev.ua designates 127.0.0.1 as permitted sender) receiver=dad.imath.kiev.ua; client-ip=127.0.0.1; helo=dad.imath.kiev.ua; envelope-from=vlasenko@dad.imath.kiev.ua; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; Cc: at@altlinux.org Subject: [devel] robot friendship [was: eclipse-platform-3.3.0-alt5_30jpp5.0 -- file deps] X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 16:38:20 -0000 Archived-At: List-Archive: List-Post: On Mon, Jan 21, 2008 at 12:54:28AM +0300, Alexey Tourbin wrote: > > +eclipse-platform-3.3.0-alt5_30jpp5.0 Requires /usr/share/java/lucene.jar > > -eclipse-platform-3.3.0-alt5_30jpp5.0 Requires lucene > У пакета eclipse-* в очередной раз "плавают" зависимости. > Дело здесь в том, что разрешение файлового пути в зависимость > идёт через механизм contents_index_all. Этот механизм по сути нужен > для того, чтобы разрешать файловые (виртуальные) зависимости в реальные > зависимости -- в тех случаях, когда такое разрешение однозначно. > > А возможно однозначно разрешить файловую зависимость в имя пакета или > нет -- это зависит от того репозитария, на котором мы собираем пакеты. > > Раньше файловая зависимость /usr/share/java/lucene.jar однозначно > разрешалась в пакет lucene. Теперь в репозитарии есть два пакета -- > lucene и lucene1, которые содержат этот файл, поэтому ничего не > остаётся, как только сохранить файловую зависимость as is. > Если же удалить из репозитария пакет lucene1, то опять "восстановится" > зависимость на lucene. > > Это наводит меня на мысль, что, по идее, сам механизм contents_index_all > в общем-то не нужен. Результат слишком сильно варьируется от текущего > состояния репозитария. Если пакет явно требует какой-то файл, то пусть > он просто требует этот файл, а дополнительный шаг по поиску реального > пакета с этим файлом ничего хорошего не даёт, а только "не по делу" > преобразует зависимость (и, кстати, ослабляет гарантию по наличию > соответствующего файла в новых сборках пакета). > > К сожалению, сейчас нельзя явно генерировать файловые зависимости между > произвольными пакетами, т.к. при формировании репозитария apt обрезает > файловые листы, так что есл пакеты находятся в разных репозитариях, то > будет так называемый cross-arch semi-unmet. > > Решения тут может быть два: > 1) отказаться от раздельных $arch и noarch репозитариев; или же > 2) не обрезать файловые листы при формировании $arch/noarch репозитариев. Прошу прощения за задержку с ответом, был крайне перегружен :( Напрашивается вариант #3. пока нет ясности с 1) и 2), генерировать зависимости, 1) в случае, если согласно content_index_all такого файла нет (вешать unmet) 2) файл есть и единственен (разрешать в зависимость на пакет) Если же согласно content_index_all файл есть, но находится в разных пакетах, то если эту зависимость нельзя разрешить на альтернативы, то вообще ее не ставить. Все равно apt ее не сможет разрешить. Зачем ее вообще ставить? это же вредительство. И робот станет другом человека :) -- Dr. Igor Vlasenko -------------------- Topology Department Institute of Math Kiev, Ukraine