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 5B78D13827E for ; Mon, 9 Dec 2013 06:53:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 88C6DE0B7C; Mon, 9 Dec 2013 06:53:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 86650E0B70 for ; Mon, 9 Dec 2013 06:53:37 +0000 (UTC) Received: from [91.220.220.251] (pinkbyte.micronet-rostov.ru [91.220.220.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pinkbyte) by smtp.gentoo.org (Postfix) with ESMTPSA id 26DC433F36C; Mon, 9 Dec 2013 06:53:35 +0000 (UTC) Message-ID: <52A5689F.1040402@gentoo.org> Date: Mon, 09 Dec 2013 10:52:15 +0400 From: Sergey Popov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131113 Thunderbird/17.0.9 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 To: Tom Wijsman CC: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead? References: <20131208175438.100112a0@TOMWIJ-GENTOO> In-Reply-To: <20131208175438.100112a0@TOMWIJ-GENTOO> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UBRXFPnmOuBgKh8NsjDormRMDi9s8C4Eu" X-Archives-Salt: d6259249-a48f-48c5-b369-5f9fcb2b6e35 X-Archives-Hash: f5a2413f263a7aef83c040dcafa68bdd This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UBRXFPnmOuBgKh8NsjDormRMDi9s8C4Eu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 08.12.2013 20:54, Tom Wijsman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hello fellow developers >=20 > =3D=3D Situation =3D=3D >=20 > When specifying a dependency like cat/pkg it will default to cat/pkg:* > which is defined in `man 5 ebuild` as: >=20 > * Indicates that any slot value is acceptable. In addition, > for runtime dependencies, indicates that the package will not > break if the matched package is uninstalled and replaced by a > different matching package in a different slot. >=20 > This default reflects different behavior than what we use slots for, > besides allowing side-by-side installations we rather use it to > specifically depend on a new major version. (eg. dev-libs/glib). >=20 > Let's say I want to a add a new major version of cat/pkg to the Portage= > tree, introducing it in the same SLOT=3D"0" isn't an option. This gives= > us two options, one is SLOT=3D"2", the other is to create cat/pkg2 or s= o. >=20 > Creating a new SLOT is the most sane thing going forward; but, as the > default (:*) depends on any SLOT, this needs a half thousand commits to= > fix up reverse dependencies. Thus, instead a new package is made. [1] >=20 > When our defaults force us down such path, that can't be good and it > affects the quality of our Portage tree; so, this makes me wonder, can > we change the default from :* to :0? What do you think? >=20 > [1] https://bugs.gentoo.org/show_bug.cgi?id=3D493652 > "media-libs/libsdl2: should be a SLOT=3D2 of media-libs/libsdl" >=20 > =3D=3D Task =3D=3D >=20 > If we agree we do this; in order to change :* to :0, we need to change > the PMS to cover this change and implement it in the package managers. >=20 > Before we do that, we need to evaluate how practical this is to apply. > While we are trying to fix the default behavior, what would changing > the default from :* to :0 break? >=20 > One thing that directly comes to mind is that dependencies that have no= > SLOT=3D"0" ebuild present would need us to manually specify a specific > SLOT; given that this is a not so common situation, the amount of > commits needed here is low. >=20 > Another thing that comes to mind is that we need to check what to do > with packages were the highest available version does not belong to > SLOT=3D"0"; technically, restricting these to SLOT=3D"0" will not cause= > breakage, it might however cause some blockers. We'll have to look > closer into how we can alleviate this result. >=20 > Is there anything else we need to take into account? >=20 > =3D=3D Summary =3D=3D >=20 > Situation: >=20 > Defaulting to :* on SLOT-less dependencies makes it hard to add a > new SLOT to a package, using :0 instead would not make this a > problem and not require to fix up all reverse dependencies. >=20 > Task: >=20 > Check results, correct some exceptions, update PMS, implement it. >=20 > Thank you in advance for participating in this discussion. >=20 In short - please do NOT do this. More complicated answer - you break the whole idea of slots. When user types 'emerge cat/foo' it means now - "i want cat/foo, whatever versions it will be(depending on mask, keywords, etc, etc)". Your proposal changes this behaviour drastically, and reasons for such changes are not worth it. --=20 Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead --UBRXFPnmOuBgKh8NsjDormRMDi9s8C4Eu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSpWigAAoJECo/aRed92678i8IAJ187DdQ33+Uor//TKIo2OeA 5V+6mYdP3DG1brkNXsyu6lyM/JSKC7rm6A2NL2v08qILKyUXfbMTFVHKv5MAeWY2 wohdcpFY4FXFP6iHlNJxLaroFG4iXk0fnVIUtGxGwVupQvzccfr6p/+t6duVosrU kpAmEdcvaLtPlaXhiHqvdEb/cJ6M+GKUuukDmW4Cdy1TUsVqMGQ9pi4SHkaHyvxu mHUvaaPcFWtGvX9TYd2wC900baK/H3G7FsWeA9aV19oEsTWreXu8MnWYpofRMM5V oXjsg/OTaHRMNLMNiMicW+wSfXPfeMkxeewhiIS8NmucaANHCK8Uzt+V/TWA+xI= =F9e8 -----END PGP SIGNATURE----- --UBRXFPnmOuBgKh8NsjDormRMDi9s8C4Eu--