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 1J1swN-0002Y4-3z for garchives@archives.gentoo.org; Tue, 11 Dec 2007 00:25:39 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBB0Oke2029205; Tue, 11 Dec 2007 00:24:46 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBB0MlRM026850 for ; Tue, 11 Dec 2007 00:22:48 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 81A6565689 for ; Tue, 11 Dec 2007 00:22:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 required=5.5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ppy2rE2H8g-N for ; Tue, 11 Dec 2007 00:22:41 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id C65AD65760 for ; Tue, 11 Dec 2007 00:22:39 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J1stL-0004tJ-Oq for gentoo-dev@gentoo.org; Tue, 11 Dec 2007 00:22:31 +0000 Received: from 82.152.205.23 ([82.152.205.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Dec 2007 00:22:31 +0000 Received: from slong by 82.152.205.23 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Dec 2007 00:22:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: [GLEP] scm package version suffix Date: Tue, 11 Dec 2007 00:27:11 +0000 Message-ID: References: <200712091701.50364.peper@gentoo.org> <200712101359.23196.rbu@gentoo.org> <8b4c83ad0712100624v5fbe6cc6q7ea1b29f44d14326@mail.gmail.com> <200712101614.50048.rbu@gentoo.org> <8b4c83ad0712101144x19e75accm7845221977a6a73f@mail.gmail.com> 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=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.205.23 User-Agent: KNode/0.10.4 Sender: news X-Archives-Salt: 7fac2f5a-90d2-44bf-b3e3-981ce351c931 X-Archives-Hash: feef1e6a18c0eae3447b0f71ad28f250 Nirbheek Chauhan wrote: > 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 don't know when the branch will be > merged), etc. > This makes a lot of sense to me. If different branches of a vcs build are to come into the tree, it only makes sense they block the main package and each other. Handling that within the package manager makes sense, since it's information that can be derived automatically. At a later stage one can envisage branches being installed to their own prefixes. >> 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. > ++ I don't find the argument for versioning the scm live ebuild compelling. The point wrt comparison, ie foo-1-scm is < 2.0.1, doesn't seem enough; it'd be better to slot that imo, and have a slot identifier[1] in the existing cvs digit space. You could still have gtk-1-cvs, for example, for packages where slots don't work. I prefer the way it works now; SLOT and cvs compares later than any other version in the same slot. (I agree the name is misleading and prefer vcs since it collides less than other options.) foo-vcs-rN # standard vcs (i prefer the explicit 0 of current spec) foo-vcsN-rN # slotted pkg foo-vcs_branch_FOO-rN # branch foo-vcsN_branch_STRING-rN ..make sense[2] and cover all the use cases that I have read about so far. It'd be useful to restrict the STRING to a simple upper case ID with a length limit; the ebuild description will give more information to a user A numeric slot id with different branches applying to the same slot would seem to be enough to track any project over its lifecycle. The id would only be visible to users choosing to install a live ebuild when the package is slotted. The reason I don't think it's a good idea to allow full versioning is that it seems to be clouding the issue. Packages are available, in slots. If the user chooses version control, it applies to the slot:pkg combination, and beyond that only needs a mechanism to choose which branch to track. Maintainers need to track ebuild revisions, and all of us, including package managers, can do with keeping things simple, imo. [1] Since SLOT is one of the most basic items in an ebuild, it's something any user making an ebuild is aware of. A vcs ebuild-writer should have no problem finding a suitable id, especially if it is to go into the tree. [2] s/vcs/whatever acronym you prefer/ -vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms -rN if missing, is implicit -r0 (compares before explicit) -- gentoo-dev@gentoo.org mailing list