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 1GTjFS-0004xq-Ik for garchives@archives.gentoo.org; Sat, 30 Sep 2006 18:07:39 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8UI6BSu032687; Sat, 30 Sep 2006 18:06:11 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 k8UI0ig9016212 for ; Sat, 30 Sep 2006 18:00:44 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 E6F096455C for ; Sat, 30 Sep 2006 18:00:42 +0000 (UTC) Received: (qmail 17571 invoked from network); 30 Sep 2006 14:00:19 -0400 Received: from unknown (HELO vapier) (192.168.0.2) by 192.168.0.1 with SMTP; 30 Sep 2006 14:00:19 -0400 From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC about another *DEPEND variable Date: Sat, 30 Sep 2006 14:01:08 -0400 User-Agent: KMail/1.9.4 References: <45126B07.6030403@gentoo.org> <200609270224.42169.vapier@gentoo.org> <20060927075422.GA7684@seldon> In-Reply-To: <20060927075422.GA7684@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="nextPart13980910.KcSX1OLUfz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200609301401.09089.vapier@gentoo.org> X-Archives-Salt: baac7cfe-af38-44f5-a916-3148b6b5edb0 X-Archives-Hash: 868dc0b37e99cfb1aefd7705486e9540 --nextPart13980910.KcSX1OLUfz Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 27 September 2006 03:54, Brian Harring wrote: > On Wed, Sep 27, 2006 at 02:24:41AM -0400, Mike Frysinger wrote: > > as i said, if you have changed ABI without an ABI bump, then the upstre= am > > package maintainer is screwing everyone who uses the package, not just > > Gentoo ... so perhaps we should be talking to them to get the situation > > resolved for all consumers, not just Gentoo > > Happens however; afaik, we also weren't monkey patching ssl in the > past to preserve the abi either so it still is valid (although rare if > upstream is behaving) scenario. we've never monkey patched ssl so i dont really know what you're referring = to > > > Bleh, this is getting back to exactly my point that it's unbounded > > > resolution. To support this, every step of execution would require > > > scanning for dangling nodes to punt; aside from invalidating -p's > > > output it *still* is a collision-protect hit. > > > > when the package upgrade detects an ABI change you recalculate the > > packages that need to be rebuilt ... > > Reiterating, this screws over any form of up front calculation; > dialup users/per minute connections can't rely on emerge -f to > actually fetch all involved sources, -p results ain't guranteed > valid, parallelization must now lock at each threads merge on the off > chance a recalc is forced. it does indeed prevent full up front calculation. we can always make the=20 behavior configurable; revdep on the fly or allow people to break it up. t= he=20 key being that their system will still continue to function as the ABI lib= =20 has been preserved automagically > > dangling nodes get recorded in the new package and considering these old > > files are not detrimental to the health of the system, you can do such a > > cleanup once at the end of the emerge > > It's not orphaning files, but your scheme doesn't work for any form of > interruption; failed builds, user intervention, etc, they all can > leave the lib stuck in the new contents. huh ? i outlined in a previous e-mail how by simply ordering the operation= s=20 sanely, there is no race condition > Dealing with that possibility means the manager has to maintain on > disk a list of the refcount of each dangling libs to decrement, > unmerge has to modify said list, etc. which is already being done in the NEEDED file ... funny how unpainless it = is=20 to generate that file > > > It also involves changing vdb nodes from "installed and usable" to > > > "installed/usable" or "lingering" > > > > no ... the old versions get merged into the new one as their existence = is > > purely hidden > > How exactly are they going to be hidden? A new file? If so, > backwards compatibility for vdb for transitioning in such a support > has to be addressed. purely hidden from the standpoint of any new package trying to use it ...=20 since you're only installing the runtime ABI library, you cannot link again= st=20 it or utilize it any way other than existing files > > > Tracking BINCOMPAT should *not* be that hard. > > > > it's one more thing to keep track of and considering all of the > > possibilities i outlined, a single maintainer can easily lose his sanity > > ... or you force wasted rebuilds on people when it's only needed in some > > circumstances > > 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=20 library (say libfoo and libbar) and only one of those changes ABI values (s= ay=20 libfoo.0 -> libfoo.1). if another package links against just libbar, you'v= e=20 got a pointless rebuild. > Seriously, maintainers ought to know *now* when they're forcing a > revdep on folks systems, I'm not seeing the massive overhead from > pushing that info into a var, nor am I seeing mass forced useless > rebuilds. there's a ton of things maintainers ought to know ... pretty soon our packa= ge=20 maintainers are going to have to be gods if they want to write an ebuild as= =20 they're going to have to know every detail about the package inside and out > 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. what's the difference ? in my scenario they dont have to do anything becau= se=20 the bump would have been caught automatically ? > 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 ot= her=20 packages ? > Besides, again, for keywording, the dev *should* be compiling it, so > there is a way to catch it :P. A revbump isn't going to break things > unless the dev is introducing something intrusive, minor version bumps > (1.1.0 to 1.1.1) shouldn't be again, introducing anything intrusive; > regardless, dev should know the high level affects of their change uhh, there is no such requirement at this time for revbumping on different= =20 arches ... currently we say the maintainer tests for his arches and leaves= =20 all the others as ~arch > Inducing a revdep-rebuild is definitely one of those high level > changes they should be aware of *prior* to the bump. and yet we look at our history of so many packages being bumped with ABI=20 changes and users having broken-as-shit systems ... i'm accounting for the= =20 worst; not hoping for the best > > or dig > > through the source code line by line and hope to catch all such cases 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=20 that you can never know completely for sure the behavior of a package witho= ut=20 digging through the entire source code. > bind the checks in as a QA measure, enabled via FEATURES=3Dstricter, > used to maintain a metadata var. a lot of things fail already with FEATURES=3Dstricter ... too bad we dont h= ave=20 per-package env var support as then maintainers could just flag all their o= wn=20 packages as stricter without wanting to shoot themselves due to everyone=20 else's package failures > Literally, pkg x version y forced a rebuild. revdep is annoying, but > stats would be useful to actually evaluate the seperate proposals; > related, getting stats for how often the various updaters were > required to be ran for a particular pkgs upgrade would be useful in > evaluating that particular gap NEEDED has. any openssl version bump where the numerical value changes ... only the let= ter=20 updates preserve ABI compat (0.9.7[a-z] are compat) expat-1.x -> expat-2.x iirc, tcl-8.3.x -> tcl-8.4.x readline-4.x -> readline-5.x ncurses-4.x -> ncurses-5.x =2Dmike --nextPart13980910.KcSX1OLUfz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iQIVAwUARR6w5EFjO5/oN/WBAQL/LA/9FCA+TQ291dRj3eFAU9BnR1p6NPaDyx4g /STz+LuRyAmBJ0N4LewWXoGxtJkbmouKuIzSg149SVrysfk0sjgMvmvcTlk/cOgf 30yCWMleDm9GcqvgXllfbmnmGXSpApub7GkCpn/VeaV7mzHdDtEauukyapCgC3g9 MQ8eya2GLmrDc1J3PVrTP8zQjYVKITmD1kkUZVQ0hVLeIDUpcjC0VO7RfcPg2kpz ju0/CeAIBESEBjDCkPo4/ptMicJsDNbOh5jsuiXYHYuKURR5vUQEIhyFCJtonqPc BNlYjsNWVq006CA7YTScpRLPLuvd3sp3P+pzUng6R6dVdMuOVlrzHzsfS/ql9N7Z sSWAyxHkwAXedZ0/tmQ0Z2JekRe/ajSunZqg2Icnnk+r0o875/BHoZdvBA7Yj9k6 93exzH9XVw1pkpxN2v1G27wZ6lfMUKyQZfHQzpQSeSdrrQDZktzHghJHbNA85DNa uwtlRLkzMZBPR9HwNQKZi/r0I9jCEwHHrdF82ddMUgR/ty5CzWE2Dzx5MwHCvU9f czcqHEQ+UKjJp7zGNNAZ2QEpf6GVIREvk8dJXh6LwLtyOmkaBefwOI9f4zr+XZNd cXzNs3GsPS4zujbwxSxJtcDi1yDe/+GZlP0aXNXHpuq+lUxMiDdL5tFjKxUKNs3U gRd44itb4h0= =B3lW -----END PGP SIGNATURE----- --nextPart13980910.KcSX1OLUfz-- -- gentoo-dev@gentoo.org mailing list