From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 21 Jan 2004 18:41:35 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] rpmlib comparison issue Message-ID: <20040121154135.GB1710@basalt.office.altlinux.org> Mail-Followup-To: ALT Devel discussion list References: <20040120164522.GA1351@basalt.office.altlinux.org> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <20040120184537.GA3204@basalt.office.altlinux.org> X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 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:41:36 -0000 Archived-At: List-Archive: List-Post: --K8nIJk4ghYZn606h Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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. -- ldv --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFADp2v9viEa8HiNCkRAmtjAJ9s4+1Ds/C5iG0sgUeaHW6o1UxlkwCfStOm CRrDbnGOWxBbHmZ0ueOi/oA= =a7wv -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h--