[devel] 4.1 FAILED srpm=rpm-build-thunderbird-2.0.0.21-alt0.M41.1.src.rpm

Led =?iso-8859-1?q?ledest_=CE=C1_gmail=2Ecom?=
Сб Мар 21 21:56:56 MSK 2009


On Saturday, 21 March 2009 20:39:11 Dmitry V. Levin wrote:
> On Sat, Mar 21, 2009 at 08:15:37PM +0200, Led wrote:
> > On Saturday, 21 March 2009 18:05:01 Anton Farygin wrote:
> > > Michael Shigorin пишет:
> > > > On Sat, Mar 21, 2009 at 06:46:05PM +0300, Anton Farygin wrote:
> > > >> Не стоит. Лучше оставить текущую схему и привыкнуть бэкпортить
> > > >> пачками на все бранчи.
> > > >
> > > > Вслепую это может приводить к их деградации;
> > > > если бы бранчи появлялись раз в полгода -- просто катастрофа;
> > > > машина должна работать, но определять -- человек.
> > >
> > > Определять что ?
> > >
> > > С деградацией по бэкпорту вслепую - согласен, можно запросто нарваться
> > > на ляп.
> > >
> > > Тогда стоит придумать какой-то другой способ обновления...
> > >
> > > может быть стоит запатчить apt (или rpm), и в веса ещё добавлять некий
> > > "бранч" (по аналогии с эпохой) ? Что бы можно было вообще отказаться от
> > > дурацких release в виде alt0.M40.1.svn13421.
> >
> > В rpm5 это реализовано.
>
> В apt (в т.ч. и у нас) есть Pin-Priority.  Но это верный путь к нарушению
> идентификации пакета (name,epoch,version,release).

Просто добавляется тэг DistEpoch. "Индентификация пакета" не нарушается, а 
расширяется.
А ещё (какой ужас!) при использовании biarch в "индентификацию пакета" 
попадает ещё и arch

-- 
Led


Подробная информация о списке рассылки Devel