From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RATSy-0007sU-Av for garchives@archives.gentoo.org; Sun, 02 Oct 2011 21:20:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D8D6821C13E; Sun, 2 Oct 2011 21:20:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id DAE3421C0DC for ; Sun, 2 Oct 2011 21:20:11 +0000 (UTC) Received: from [192.168.168.169] (dyn-199-173-dsl.vsp.fi [83.146.199.173]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ssuominen) by smtp.gentoo.org (Postfix) with ESMTPSA id CCD141B4009 for ; Sun, 2 Oct 2011 21:20:10 +0000 (UTC) Message-ID: <4E88D5A1.1010409@gentoo.org> Date: Mon, 03 Oct 2011 00:20:33 +0300 From: Samuli Suominen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111002 Thunderbird/7.0.1 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: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild References: <20111001170259.E4D702004B@flycatcher.gentoo.org> <201110021420.47397.vapier@gentoo.org> <4E88C2DE.6000005@gentoo.org> <201110021611.03344.vapier@gentoo.org> <4E88CC32.9020708@gentoo.org> In-Reply-To: <4E88CC32.9020708@gentoo.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 557d79695085e445bb89b7e5ddea9092 On 10/02/2011 11:40 PM, Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n wrote: > Mike Frysinger schrieb: >> the system is functioning wrongly because you're forcing users to need= lessly=20 >> upgrade/downgrade packages. in addition, packages in the tree aren't = the only=20 >> things to be considered. if the user is building code that works fine= against=20 >> the latest stable, but your package forced it to downgrade, they might= no=20 >> longer build correctly. >=20 > Then the code is broken that is built outside portage and does not > function correctly with old linux-headers without doing any kind of > version check. That too, no doubt about it, but that doesn't invalidate what Mike already said. > And again, downgrade of dependencies it is not against any rule which > would justify mask and removal. >=20 > Another example from the X.org packages, installing the proprietary > ATI/NVidia drivers will cause downgrades for xorg-server on ~arch > systems. Nobody in his right mind is proposing to treeclean them becaus= e > of this. >=20 The new xorg-servers could get package.masked until these major drivers are available. Albeit, I'm not intrested in pursuing this since with separate xorg-server package, it's the drivers that need rebuilding against it, and the VIDEO_CARDS=3D"" setting is keeping it in certain version until the VIDEO_CARDS=3D"" setting is satisfied. Poor example to make a case. >>>> further, when the newer version gets stabilized and then the older o= nes >>>> dropped, what then ? your package is broken. >>> >>> Yes, when the older one is dropped _that_ would be reason for >>> masking+removal. However I have not seen any plans of doing so. Actua= lly >>> the current amd64 stable 2.6 versions are 35, 26 and 10 months old >>> respectively, I wouldn't expect that to happen any time soon. >> >> sorry, but that's irrelevant. the lack of tree-cleaning is more due t= o=20 >> missing automatic generation of ChangeLog files. but if this is going= to be a=20 >> sticking point for you, i can simply clean the tree as soon as we get = newer=20 >> stable versions. >=20 > If the old versions and reverse dependencies are dropped in accordance > with > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3D2&cha= p=3D5#doc_chap7 > then I won't complain. The intresting part of that document is "You should also not cause an unnecessary downgrade for any "~arch" when ..." which also applies to setting dependencies just as well.