[devel] Fwd: E: incoming i586 reject: wmmemload-0.1.6-alt4

[Dmitry V. Levin]

On Mon, Oct 08, 2007 at 07:30:38PM +0300, Victor Forsyuk wrote:
> On Sat, Oct 06, 2007 at 12:45:07PM +0700, Slava Semushin <slava.semushin на gmail.com> wrote:
> > 2007/10/5, Victor Forsyuk <force / altlinux.org>:
> > [...]
> > > > Что-то странно как-то всё. Я не правил патчи и в спеке все изменения
> > > > были не функциональными, а пакет не собрался на обеих архитектурах.
> > > > При этом тот, что в Сизифе вроде бы пересобирается без проблем.
> > >
> > > Да, в спеке все изменения были нефункциональны. Но есть один маленький
> > > нюансик. Исходный тарболл в wmmemload-0.1.6-alt4.src.rpm побайтово идентичен
> > > тому, который был в -alt3.src.rpm, но отличается датами файлов. В нем всё
> > > "тачнуто" в "Oct  5 08:15". Откуда это появилось?
> > 
> > Ну как откуда? Я же этот пакет засунул в git и теперь тарболл
> > генерируется на лету. Видимо, отсюда и дата.
> 
> Я вполне себе могу представить программу, сборка которой не сломается от
> таких вольностей с исходниками, но которая будет собираться неправильно.
> Ничего сверх-ухищренного. К примеру, при сборке используется самый свежий
> файл по какой-то маске имен из определенного каталога... Не самое умное
> решение, но много ли вы видели идеальных апстримов? И это даже _не ошибка_
> автора (как упаковка того же autom4te.cache), а просто freaky way.
> 
> Вы готовы поручиться, что у пакетов, которые Вы таким образом собираете из
> git подобных проблем не будет?

За свои пакеты я готов поручиться, поскольку я имею привычку сравнивать
логи сборки.  Но априори исключать влияние timestamp'ов в тарболе на
сборку, конечно, нельзя.  Такие грабли следует репортить upstream по мере
обнаружения.


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20071008/09abfa53/attachment-0002.bin>