From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GUNME-0008AJ-0b for garchives@archives.gentoo.org; Mon, 02 Oct 2006 12:57:18 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k92CuOs3029413; Mon, 2 Oct 2006 12:56:24 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k92CrMAG012466 for ; Mon, 2 Oct 2006 12:53:23 GMT Received: from home.wh0rd.org (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 5265C64723 for ; Mon, 2 Oct 2006 12:53:21 +0000 (UTC) Received: (qmail 29093 invoked from network); 2 Oct 2006 08:52:24 -0400 Received: from unknown (HELO vapier) (192.168.0.2) by 192.168.0.1 with SMTP; 2 Oct 2006 08:52:24 -0400 From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC about another *DEPEND variable Date: Mon, 2 Oct 2006 08:53:55 -0400 User-Agent: KMail/1.9.4 References: <45126B07.6030403@gentoo.org> <200609301401.09089.vapier@gentoo.org> <20060930193430.GA9496@seldon> In-Reply-To: <20060930193430.GA9496@seldon> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1609068.DYtnXRMDnr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200610020853.55757.vapier@gentoo.org> X-Archives-Salt: 65f8abbf-076c-49e9-831a-dfde899363c8 X-Archives-Hash: 08c60029b22f58217130257e5e4b6899 --nextPart1609068.DYtnXRMDnr Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 30 September 2006 15:34, Brian Harring wrote: > If that's what folks want, sure, but what you're proposing is just > sliding NEEDED in as the defacto solution without labeling it as such. no idea what this means > Re-read your emails, and mine please. The scenario I pointed out was > ctrl+c'ing the merge while it's doing a rebuild for lib1 to lib2. then let me turn it around ... how exactly does your solution account for a= ll=20 these little details ? i dont recall you outlining anything ... > > > How exactly is this forcing wasted rebuilds? You're stating that > > > maintainers are going to bump it willy nilly. As I said, it is a key > > > that would be bumped *as needed*, and would only affected pkgs that > > > specified that node as a binding dep (specially marked atom). > > > > no, i mean for example scenarios where a package provides more than one > > library (say libfoo and libbar) and only one of those changes ABI values > > (say libfoo.0 -> libfoo.1). if another package links against just > > libbar, you've got a pointless rebuild. > > If one changes it's version, it's a fair bet that any consumer of that > pkg is linked to more then just that lib; as such they would be > rebuilt *anyways*. it isnt guaranteed ... you asked for a pointless rebuild and i gave you=20 one ... one that is not falsely flagged when reviewing the NEEDED list the other example is where the ABI changes for one arch but not for any=20 other ... what do you do, force ABI rebuild for everyone ? ok, maybe that= =20 arch was x86 so we say screw you to the smaller arch teams ... but what if= =20 that arch was a smaller arch team ? > Sorry, but if a developer is bumping a pkg and doesn't even look to > see if the damn thing is potentially going to break others via soname > changes, that maintainer is being an idiot. and yet it does happen and again, we're looking at this from different=20 angles ... you'd rather assume the developer is 100% competent and never ge= ts=20 things wrong; i'd rather assume nothing and let the details be discovered=20 automatically. in the end, the people using Gentoo are the ones that suffer and i'm tired = of=20 seeing systems broken beyond usuability because a developer unleashed a=20 package without realizing the consequences of it > > > Realistically, just the same as the NEEDED solution has holes, the > > > maintaining dev can screw up and miss a BINCOMPAT bump. Difference is > > > that they can do something for BINCOMPAT; hell, QA checks can be > > > automated to catch missing BINCOMPAT bumps. i bet a post-emerge would make this painless and automate the QA step ...=20 after src_install(), you run something like `scanelf -qsRS ${D}` and save t= he=20 results in vdb/SONAME ... and then on subsequent installs, you run it again= =20 and if the SONAME changes but BINCOMPAT did not, you bail with a die messag= e=20 telling the user to go file a bug and preventing the merge which would have= =20 broken his system > > > KEYWORDed arches bit, bit unlikely that the underlying arch is > > > actually going to screw with the soname, thus I'd want actual examples > > > backing it up. > > > > how about libc.so from glibc and libgcc.so from gcc ? or would you like > > other packages ? > > Considering such a change would be internal ABI, NEEDED doesn't > actually fix anything; if it were a soname change, level playing > ground again. it is a SONAME change, why else would i mention this > Reiterating; devs should know the high level affects of their changes. reiterating: you're hoping for the best; i'm looking at our history and=20 assuming that devs will make mistakes as everyone does > If it's going to change the soname version, they should know from the > get go- unless it's an arch specific breakage (which I still posit is > the rare/corner case), they will *see* it for their arch and bump it > already. maybe, but it's still a possibility which analyzing of SONAME would catch > Stating that things are broken doesn't make NEEDED automagically > better either; *both* enable a way to fix it, so you need to justify > the "accounting for the worst; not hoping for the best". justify how ? would you like me to dig up the bugs where devs bumped packa= ges=20 into stable and the SONAME change broke a ton of people's systems ? has it= =20 never happened to you ? > > > > or dig > > > > through the source code line by line and hope to catch all such cas= es > > > > by hand/eye ? > > > > > > Bit of FUD here, although I spose I'll just point out that if so's > > > change as massively as you're implying above, the affects on -p are > > > that much worse. > > > > awesome, mark something you disagree with as FUD, problem solved. my > > point is that you can never know completely for sure the behavior of a > > package without digging through the entire source code. > > It's FUD due to the fact NEEDED suffers the same fucking issue. The > irony is that BINCOMPAT would at least give a knob to mark it as a > breakage, NEEDED cannot. and then you get angry ? try to have a discussion without getting all anxi= ous=20 as that only wastes time there's a few issues here, not just one ... - ABI change w/no SONAME bump - impossible to catch without reading source= ;=20 BINCOMPAT would allow for it; NEEDED would not - ABI change w/SONAME bump - BINCOMPAT would not catch; NEEDED would > Frankly, if you don't believe me or think my points are correct about > how a NEEDED based solution is going to suck, zac/jason/genone/anyone > else. They're going to point out the same flaws. if you dont want to hash out ideas on a development list but rather just=20 declare one right and one wrong, then feel free to leave. if you're confus= ed=20 about my intentions here then let me set you straight. i see advantages to= =20 both sides and i'm going to argue out problems until we have something good= =20 to push back into portage. i dont really care if the final solution is "my= =20 idea" or not; such personal ties is just stupid and helps no one. =2Dmike --nextPart1609068.DYtnXRMDnr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iQIVAwUARSEL40FjO5/oN/WBAQKcKw/+JUAkvxFl6aTxUh8fim+SWmPDqOb7HAtY qsjieZdbT9uN8qZxRzflwbExVzjgcbTQ7EtqmVeh9svsS1Ykn8DlV6jdf6bUPCgH YbGQkmw8IJeplkt98v9XcQRPNBDnfdQTUnzKaf5BdnAcYNfHjeRTs1/FEOp0gwoy aO+7SCjwKp3XWVhWQMRApyKMfAydhuKtoV8U5w2yPqSTsGZ2fFDTpu1LNzxtlErd wXHWjH1haCUEpsjv7LPQQQiQh65x9eEJKm+YiamAmjm2dGYPrlT+ScdiYNMouKHS QiTLYmFiPSQITdJeh68Np6WUksqPz0b5IYMmOENxA5ZCXwwpIjDw0rFo2rHdNhA1 Xy80WAIQZw76gkseBNZut3jg4PLN4UMxU/Q9r0RAUhf6S5HI6+CqanCA+6OP0ZrE PosT/NZtrSUDBDuuYWXb//UMIEYXHkT9YwImpiHkUn9G7wF7hLj3FWp8gp8n2Jpp l4liNbYeYxZy4VAt8u6q5UOrNDN0qnZmiJlXqMyrnZRg0mhLkWwB2dWrSyUBcgAv sRgoRz+Q1DHi/r753KTNHuiSow9Ww314ZlqDawcxrzasPRtxRVrQKuklO2AdkW7V 5KP+c9WGzI3qTXCYy3WEhjKjfPcai+x3YmhnDijsJNrUYIHM1vHfxhXmD1mPYJQK 5U+xNNkRLaU= =6X2c -----END PGP SIGNATURE----- --nextPart1609068.DYtnXRMDnr-- -- gentoo-dev@gentoo.org mailing list