From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 20 Jan 2004 21:45:37 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] rpmlib comparison issue Message-ID: <20040120184537.GA3204@basalt.office.altlinux.org> Mail-Followup-To: ALT Devel discussion list References: <20040120164256.GB7137@master.mivlgu.local> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20040120180759.GA2913@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: Tue, 20 Jan 2004 18:45:43 -0000 Archived-At: List-Archive: List-Post: --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 ? -- ldv --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFADXdR9viEa8HiNCkRAmNcAJ9ZQtQJJIqydBw7wbFG86hyZjqjFgCdHjwX GhukJyZF0qgNTXVpyVuHxuk= =WW4n -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--