From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1J1obU-00030I-Jq for garchives@archives.gentoo.org; Mon, 10 Dec 2007 19:47:49 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBAJkxgi032597; Mon, 10 Dec 2007 19:46:59 GMT Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBAJi6Yi028512 for ; Mon, 10 Dec 2007 19:44:07 GMT Received: by rv-out-0910.google.com with SMTP id b22so1607078rvf for ; Mon, 10 Dec 2007 11:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xzqPpgbmyS3sxML4tTUf2qYUWSSb5A2KXF3lT3qqJ+s=; b=P13k6e3mJUIP1JGxk5g4ti1fBlSL28OgXugGhYMONwMyGz8rxcHSPwEqjMqymoEKU33q27d0JyhRF+y9lFY/URMZiRSQ4Zmu7oRquShQg5U+ZH+JkB2SxFoAWRZ3N/eOpGhBOdFa8ftPnV0njchZafu61vLykpVfBkYTM3Zrnoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QfRa4lrbg2GjlSq2ZaVS/7a6khFQHaz9aU/8vbUF9fltQFZb3MT1oZFiqMcdahqnGYSDzHHMh0QlGiJjFU93UWldoizLiE0z5x2iak+ivkNpyfK4E2W6wQeCftku9m3JuoO9MxhvD/0I59/Qlz2zavMYuXEd4fT0exfXsl515PY= Received: by 10.141.185.3 with SMTP id m3mr1255344rvp.1197315846189; Mon, 10 Dec 2007 11:44:06 -0800 (PST) Received: by 10.140.142.10 with HTTP; Mon, 10 Dec 2007 11:44:06 -0800 (PST) Message-ID: <8b4c83ad0712101144x19e75accm7845221977a6a73f@mail.gmail.com> Date: Tue, 11 Dec 2007 01:14:06 +0530 From: "Nirbheek Chauhan" To: "Robert Buchholz" Subject: Re: [gentoo-dev] [GLEP] scm package version suffix Cc: gentoo-dev@lists.gentoo.org In-Reply-To: <200712101614.50048.rbu@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200712091701.50364.peper@gentoo.org> <200712101359.23196.rbu@gentoo.org> <8b4c83ad0712100624v5fbe6cc6q7ea1b29f44d14326@mail.gmail.com> <200712101614.50048.rbu@gentoo.org> X-Archives-Salt: 55cc8525-8b71-4a83-a836-a9664ae001c9 X-Archives-Hash: 7c4c5a27bf9a34d52ad25e6f8271972d On Dec 10, 2007 8:44 PM, Robert Buchholz wrote: > That would still mean everything relies on n ebuilds with mutual blocks. > Even if that would work and it block upgrades, it is still not a > solution in terms of how to display a list of ebuilds in one tree in an > ordered list. The mutual blocks can be via the very nature of the name of the ebuild (ie, the scm_bbranch), and not via unmaintainable dep blocks in the ebuilds. This could be similar to the way SLOTS are handled. In fact, as Donnie and Santiago discussed in the other "branch string" thread, the concept of SLOTS could be extended to branches with no concept of an "upgrade" between them, and them being mutually blocking and perhaps blocking the actual package as well. Of course this could be extended to apply only to branch ebuilds without a version number (where you know when the branch will be merged), etc. > You are right. But this just shows that named feature branches do not > fit the context of this GLEP, as you usually cannot know when a feature > will be merged at the time one version is branched. Completely removing the concept of an "upgrade" from (unversioned?) branch ebuilds and making them block all other versions of the package will give the task of knowing when a feature has been merged to the user itself. Which is after all what one does manually while working on branches. -- ~Nirbheek Chauhan -- gentoo-dev@gentoo.org mailing list