From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 21 Jan 2004 18:46:11 +0300 From: Sergey Vlasov To: ALT Devel discussion list Subject: Re: [devel] rpmlib comparison issue Message-ID: <20040121154611.GF2038@master.mivlgu.local> Mail-Followup-To: ALT Devel discussion list References: <20040120165947.GC7137@master.mivlgu.local> <20040120171229.GC2219@basalt.office.altlinux.org> <20040120172659.GI2013@pyro.hopawar.private.net> <20040120172755.GB2519@basalt.office.altlinux.org> <20040120174037.GK2013@pyro.hopawar.private.net> <20040120174449.GA2717@basalt.office.altlinux.org> <20040120175937.GM2013@pyro.hopawar.private.net> <20040120180759.GA2913@basalt.office.altlinux.org> <20040120184537.GA3204@basalt.office.altlinux.org> <20040121154135.GB1710@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9ADF8FXzFeE7X4jE" Content-Disposition: inline In-Reply-To: <20040121154135.GB1710@basalt.office.altlinux.org> X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 15:46:15 -0000 Archived-At: List-Archive: List-Post: --9ADF8FXzFeE7X4jE Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Jan 21, 2004 at 06:41:35PM +0300, Dmitry V. Levin wrote: > On Tue, Jan 20, 2004 at 09:45:37PM +0300, Dmitry V. Levin wrote: > > On Tue, Jan 20, 2004 at 09:07:59PM +0300, Dmitry V. Levin wrote: > > > On Tue, Jan 20, 2004 at 11:59:38PM +0600, Alexey Morozov wrote: > > > > On Tue, Jan 20, 2004 at 08:44:49PM +0300, Dmitry V. Levin wrote: > > > > > > Да, Вы правы, неэквивалентна. Значит, нужно править спеки ядреных > > > > > > пакетов. > > > > > Не только. Ещё и rpmbuild надо править. > > > > Ну, я уже говорил, что в 4.0.4-alt27, вроде, все нормально. > > > > По крайней мере, когда rpmbuild запускается из-под xemacs :-)) > > > > > > Всегда жаль, когда такие приятные иллюзии рассеиваются. > > > > > > Увы, фиксить надо даже не rpmbuild, а librpm. > > > > С большой натяжкой это можно назвать документированным поведением: > > > > rpm-4.0.4-alt28/lib/depends.c:rpmRangesOverlap > > int rpmRangesOverlap(const char * AName, const char * AEVR, int AFlags, > > const char * BName, const char * BEVR, int BFlags) > > [...] > > /* If either EVR is non-existent or empty, always overlap. */ > > if (!(AEVR && *AEVR && BEVR && *BEVR)) { > > result = 1; > > goto exit; > > } > > > > rpm-4.3-0.7/lib/rpmds.c:int rpmdsCompare(const rpmds A, const rpmds B) > > [...] > > /* If either EVR is non-existent or empty, always overlap. */ > > if (!(A->EVR[A->i] && *A->EVR[A->i] && B->EVR[B->i] && *B->EVR[B->i])) { > > result = 1; > > goto exit; > > } > > > > Т.е. если один из сравниваемых пакетов не имеет информации о версии, то > > сравнение версий считается успешным. > > > > Поскольку у нас все реальные пакеты имеют информацию о версии, то этот > > казус проявляется только тогда, когда хотя бы один из сравниваемых пакетов > > является виртуальным и не имеет информации о версии. > > > > Вопрос, насколько такое поведение является логичным? > > Другими словами, насколько логично принимать допущение, что > > (NULL > 7) == true && (NULL < 7) == true ? > > Всем спасибо за конструктивные предложения. > > Я принял решение изменить алгоритм rpmRangesOverlap таким образом, чтобы > при сравнении двух пакетов в случае, когда ровно один имеет версию, версия > другого (не имеющего версию) пакета принималась равной -infinity. А мы при этом не получим конфликт с upstream, последствия которого потом придётся разгребать долго и мучительно? Что там думают по этому вопросу? --9ADF8FXzFeE7X4jE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFADp7DW82GfkQfsqIRAn5bAJ423/dWk7a5q2I+2BfubQAVmnJ8dwCfTLIy 6/wwN/BGdJAcDw3pHkvLa/Y= =6fmE -----END PGP SIGNATURE----- --9ADF8FXzFeE7X4jE--