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 0618F138247 for ; Fri, 17 Jan 2014 23:57:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DB903E0A6F; Fri, 17 Jan 2014 23:57:38 +0000 (UTC) Received: from albert.telenet-ops.be (albert.telenet-ops.be [195.130.137.90]) by pigeon.gentoo.org (Postfix) with ESMTP id C35AEE0A53 for ; Fri, 17 Jan 2014 23:57:36 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by albert.telenet-ops.be with bizsmtp id FBxb1n00d2khLEN06Bxbak; Sat, 18 Jan 2014 00:57:35 +0100 Date: Sat, 18 Jan 2014 00:56:36 +0100 From: Tom Wijsman To: ciaran.mccreesh@googlemail.com Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy Message-ID: <20140118005636.107ac4af@TOMWIJ-GENTOO> In-Reply-To: <20140117182841.714036d5@googlemail.com> References: <20140114213719.GA2684@laptop.home> <52D6715F.8000502@gentoo.org> <20140115153036.GA1433@laptop.home> <52D77990.7060506@gentoo.org> <21209.19690.272098.806760@a1i15.kph.uni-mainz.de> <20140117174758.712c4285@TOMWIJ-GENTOO> <20140117182841.714036d5@googlemail.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_//93eshlZ3H9eqP5qpC6Otw2"; protocol="application/pgp-signature" X-Archives-Salt: be2ca5ab-aa83-4941-bc8d-c3d391e10687 X-Archives-Hash: 63f0d60b1a0ee55d1d96ee382f5bebec --Sig_//93eshlZ3H9eqP5qpC6Otw2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 17 Jan 2014 18:28:41 +0000 Ciaran McCreesh wrote: > On Fri, 17 Jan 2014 17:47:58 +0100 > Tom Wijsman wrote: > > Maybe we can let the package managers only perceive it as keyworded > > or stable if all of its dependencies are keyworded or stable on the > > architecture that the user runs. Then we can have repoman just > > ignore checking dependencies' keywords when we keyword or stabilize > > them. > >=20 > > Not sure how implementable this idea is though... >=20 > It's going to hurt for four reasons that I can think of right now. >=20 > Firstly, things you think are "obviously portable" sometimes aren't. We could write a search for architecture dependent / specific code. > Secondly, users already get confused by "stable use masks". This is > going to be even worse: users aren't going to understand why a noarch > package isn't available for them. We can improve the output of the package manager to make this easier to understand; one way is to clarify it, the other way is to just replace it by the actual archictecture the user runs. As a side note, I think we might want to name this anyarch... :) > Thirdly, you have to decide how to deal with long chains and cycles in > noarch dependencies. > > Fourthly, the interaction with || deps is an awful mess. Yes, these are though problems to resolve; my mind came up with that this idea needs recursion, hence the "not sure how implementable". A cycle can be broken by stopping to continue to a certain dependency if that dependency is of the parent reverse dependencies, capture the set of packages as a cycle. Then check for each package in the cycle if their dependencies satisfy each package; if so, all the packages in the cycle are satisfied. Of course, this doesn't take into account more complex cycles were two cycles are connected to each other; but if we would have such thing, I'd rather see that get fixed in the Portage tree as that sounds like a needlessly complex set of ebuilds. Long chains might or might exist and might or might not be problematic, that's something we would need to test out when this is implemented. || deps can be done, just check them in the same order like before; what I'm more scared of is the amount of anyarch/noarch there would be added to the Portage tree, just a few can be easily done. If it is going to be a large share of the Portage tree we'll want to look for another design or just not change how this works at all.=20 --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_//93eshlZ3H9eqP5qpC6Otw2 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS2cM0AAoJEJWyH81tNOV90JoH/0N3CQxTN2Jt29gAQXyd+SyG rCSH+ECZYQT3ln+A+Jos/l2IswM00VbN2w4kkXOF/aagiU2ZDsXHgoZEogszcj1f 1RoK8l2qCeJmOD9+F+ZqO6lmR/migesB+Di96ixn/wqrsFqcr/7+Meml0hmDagct hkUw/No6L1qlg9TCmoT8CIXf7IAmsWg0cerN9KbTfTT8+kK80nEb4NVNXTn/trFG JzEIsyiMYzoMd2og/tlbSa8FExPFQLyEmEOa5u9iuwoL61mEHm8M36NQOCA/+BgG ezBUfshcSN0FlhifAOdfRsv3+GHVYc0SY+mQQoQGN7Z8/UdBAgiQd8RvIthxUtg= =JYxr -----END PGP SIGNATURE----- --Sig_//93eshlZ3H9eqP5qpC6Otw2--