From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-project+bounces-2197-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 96D37138010
	for <garchives@archives.gentoo.org>; Wed, 31 Oct 2012 00:02:08 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 0A86321C028
	for <garchives@archives.gentoo.org>; Wed, 31 Oct 2012 00:02:07 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
	by pigeon.gentoo.org (Postfix) with ESMTP id 79CD021C129
	for <gentoo-project@lists.gentoo.org>; Tue, 30 Oct 2012 22:06:31 +0000 (UTC)
Received: from [192.168.178.26] (e178071245.adsl.alicedsl.de [85.178.71.245])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: chithanh)
	by smtp.gentoo.org (Postfix) with ESMTPSA id 4D6BE33D799
	for <gentoo-project@lists.gentoo.org>; Tue, 30 Oct 2012 22:06:30 +0000 (UTC)
Message-ID: <50904F66.8070808@gentoo.org>
Date: Tue, 30 Oct 2012 23:06:30 +0100
From: =?UTF-8?B?Q2jDrS1UaGFuaCBDaHJpc3RvcGhlciBOZ3V54buFbg==?=
 <chithanh@gentoo.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121024 Firefox/16.0 SeaMonkey/2.13.1
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Reply-To: gentoo-project@lists.gentoo.org
MIME-Version: 1.0
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012
References: <20121030150024.GU85698@gentoo.org>
In-Reply-To: <20121030150024.GU85698@gentoo.org>
X-Enigmail-Version: 1.5a1pre
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Archives-Salt: 247187b4-3046-43e9-af0c-d7dbc7f0a809
X-Archives-Hash: b20048140e8a261569fe4a1d561df6c6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

I wish to ask that the council makes a statement regarding the policy
on "<" versioned dependencies.

Some time ago one of the ebuilds that I maintain was removed twice
without my consent, the reason given that it violates an alleged
policy which forbids <sys-kernel/linux-headers-2.6.38 dependency[1].
After some discussion, the issue was resolved by fixing the build with
newer linux-headers. About the policy itself, no consensus was reached.

The issue came up again later[2] and also recently with some x11
maintained packages[3]. Today in the boost discussion thread on -dev
it was brought up too.

If I understand correctly, the proponents of this policy call for some
kind of reverse visibility requirements, where stabilizing or
unmasking a package requires all reverse dependencies on that slot to
work with the newly stabilized/unmasked version.

I dispute that such a policy exists, and am not aware of any
authoritative document that says so. When asking for documents that
describe this policy, I was only pointed to common sense.

The reason why I think that < dependencies are not bad is that
existing users of such packages will typically simply miss out on
upgrades. Worst case is that trying to newly install a package can
lead to downgrades or slot conflicts. But the user can see this before
the build starts, and still decide to abort or uninstall one of the
problem packages.

The reason why I think that forbidding < dependencies is bad is that
in the case of x11 maintained packages, their development speed is
non-uniform. Especially new xorg-server releases can have certain
x11-drivers packages depend on old versions for weeks or even months.
Masking xorg-server will hinder X.org progress for everyone else, and
removing the drivers that continue to work fine with old xorg-server
would be a disservice to users.

I therefore ask the council to:
1. State whether such a policy exists
2. If it exists, repeal this policy
3. If the policy exists and is not repealed, state what is done with
packages in violation of that policy (e.g. must they be treecleaned,
or is it sufficient to p.mask them or drop to ~arch?)


Best regards,
Chí-Thanh Christopher Nguyễn


[1] https://bugs.gentoo.org/show_bug.cgi?id=361181
[2] https://bugs.gentoo.org/show_bug.cgi?id=414997
[3] https://bugs.gentoo.org/show_bug.cgi?id=439714
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCQT2YACgkQ+gvH2voEPRB7OACePIMpS1g/G3vQ/yUp2/ngSMVB
1W0AnRANyPZoANZ8mW4ErjcrwS/+wSuH
=mzoU
-----END PGP SIGNATURE-----