From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 81DE8138C52 for ; Sat, 11 Apr 2015 23:20:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 64FC0E0B35; Sat, 11 Apr 2015 23:20:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D311DE0B35 for ; Sat, 11 Apr 2015 23:20:38 +0000 (UTC) Received: from localhost (sloan0.ut.mephi.ru [85.143.112.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bircoph) by smtp.gentoo.org (Postfix) with ESMTPSA id 80EAA3408AE for ; Sat, 11 Apr 2015 23:20:37 +0000 (UTC) Date: Sun, 12 Apr 2015 02:20:33 +0300 From: Andrew Savchenko To: gentoo-devhelp@lists.gentoo.org Subject: [gentoo-devhelp] How to properly handle deps for stabilization or version bumps? Message-Id: <20150412022033.cce77bd0e70844d01d45a951@gentoo.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.25; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Development-related help X-BeenThere: gentoo-devhelp@gentoo.org X-BeenThere: gentoo-devhelp@lists.gentoo.org Reply-To: gentoo-devhelp@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Sun__12_Apr_2015_02_20_33_+0300_IZGs7IpsqWiOj06H" X-Archives-Salt: 1980d77f-0f96-4365-b109-f83407be6cb8 X-Archives-Hash: 6234464f9b16accdb54fd3c0f373db1e --Signature=_Sun__12_Apr_2015_02_20_33_+0300_IZGs7IpsqWiOj06H Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I have a couple of concerns about a proper way of handling complicated dependencies during version bumps or stabilization. I. With some USE flags combinations package foo depends on bar and vice versa. While with a properly set deps (e.g. PDEPEND) this is not a problem for users during updates; but this is a problem during commits: repoman doesn't allow to commit multiple packages at once, so for a short period of time deptree will be broken during version bumps or stabilization. E.g.: sci-physics/root: PDEPEND on ~app-doc/root-docs app-doc/root-docs[api] DEPEND on ~sci-physics/root I see three possible solutions: 1) commit both packages with short window between (e.g. minute or two); 2) ask infra to block cvs <-> rsync tree syncs for a while; 3) temporarily mask USE=3D"api" for root-docs, commit root-docs, commit root, unmask USE=3D"api". Second option looks like overkill and IMO should be used only for large scale operations like mass eselect package moves. Third option is formally correct, but it requires double modification of tree-wide file where any mistake may broke the whole tree. I think this approach brings more risks than benefits for a simple issue described above. Currently I use first option, since probability of broking deptree is low and affected audience will be very limited. Any idea how to handle this issue better? II. What to do if package stabilization requires to stabilize deps maintained by other devs? Should I just file a bug with stabilization request to a corresponding dev or team? What to do if I have no version requirements for a version to be stabilized? E.g. app-doc/root-docs needs dev-haskell/pandoc-citeproc, but it seems to work with any version in tree. Probably in will be the best for a relevant team to pick up a stabilization candidate for their convenience. Should I add arches there? Since I'm not a maintainer of a dependency package I'm not sure if I can do that. Package may require some dependencies to be stabilized as well... If I'm sure that some package (e.g. dep of my package) works fine and I see that it has no unstable deps or critical bugs, may I CC arch teams and ask for stabilization myself? Pros here are that this will speed up stabilization process and lower overhead for other devs, cons are that package maintainer may be aware of some issues preventing stabilization of this specific version. Best regards, Andrew Savchenko --Signature=_Sun__12_Apr_2015_02_20_33_+0300_IZGs7IpsqWiOj06H Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVKaxBAAoJEPZTWjO6HuSN9BsP/jOjpEk0eZszfe0+ZiAWUFlM BRdoe/8x4DiUWd7Plv8HNb3dLQKUu/e/wCfdc5tHNqkTeq1Ju1iY3KR9SVkhekyl sR5aRa0i9n5i/iRJgDO2f5Zb2v+Cl/NxgGOIVhRzTIVSTixPdfF13mXTbfmSrtu7 ys+CojFlyzU+RWxyUrhGE/bQWROQ4Xs6HVnZBouSk8S6Uh0Ukl7T05qMCKUBGN6g QXEugc2NOOxFwZeUS5MxvEM4BrmjrDOZa06k2Ukc3Z0UalUpT8dOQEqtP/Ur9pMW +RiGx3elduI+dXMWxPYq9yCvrcTj1ukFL+DDzCp+NENVuhX+0XBt5XCqAXcRMQaZ EnN6hJExCJ6r+8g0daQHZ7r4vJSjPUiqDjg7emy0YP+WdrNO/YWYSTMu7HnKaupm jgOT2k50yASxFcXkvpm+BubcMAo0X9EfAAVkpODJ0t+4gZ/Fna6Y+Ws/uBqngOaG P0iIBHGRbBEOL9VWiOwwcJKE/tU4NpMqdC5TvjVAl6qmIb3VAKzYNDE6ejc2fMgy ZcTIOj3Wgxdey6vN017EI7l7lnLz7AcqJfEVEYqQO05wq6lvx/H+o4ju2SoYPBst uQlbPeJ4tyXA4hWJnNIAoGvRH2O5/SlPmVjUptem2nV0ME7cNh7Oe+qtxCPE5ezj wEEiKU87eXvG+kmqzzFD =lQtR -----END PGP SIGNATURE----- --Signature=_Sun__12_Apr_2015_02_20_33_+0300_IZGs7IpsqWiOj06H--