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 1LgoFs-00067R-Uk for garchives@archives.gentoo.org; Mon, 09 Mar 2009 22:47:29 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 706ACE03EB; Mon, 9 Mar 2009 22:47:28 +0000 (UTC) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.156]) by pigeon.gentoo.org (Postfix) with ESMTP id 458A6E03EB for ; Mon, 9 Mar 2009 22:47:28 +0000 (UTC) Received: by yw-out-1718.google.com with SMTP id 4so924748ywq.46 for ; Mon, 09 Mar 2009 15:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:date:from:to :subject:message-id:mime-version:content-type:content-disposition :user-agent; bh=56Cp9V4s0Lwz3tggHVUatjW3JFuPJRvmcTn3RRu1r4I=; b=aRYifeP+2Uga1wLrK0ooXi45Z+BPghOvUUPs/tsg5YfHlB3LAUbE3MIvI6Ok0MyF40 mDWmaJ4inHwFUUrKOGPTE5ajz55Duac5CtSFPCflmaGyMAbsqPn6g1UHOk9AuZevKXSL QXTp8cfaklsbSbKDPj4ZTNc6MC2UQDkvqc8fE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=EkAJ4T+PPm8ZqgHurCTdkznL1LCakxGKhBsrtquXdRraghlyNJqZdHWjZbVvHCLnDB vM/D1znUJA2o0mwvvvTPTh3R8Cy4C5MKsaXG04yBh5422qW/3OQCaA0PAFGiJRTlK6u7 84gpqBBjvOi5eTcVe/59cJklHMa3Nuv9smD5g= Received: by 10.150.201.17 with SMTP id y17mr11619733ybf.138.1236638847068; Mon, 09 Mar 2009 15:47:27 -0700 (PDT) Received: from smtp.gmail.com (c-69-249-154-72.hsd1.nj.comcast.net [69.249.154.72]) by mx.google.com with ESMTPS id z26sm11200549ele.0.2009.03.09.15.47.26 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Mar 2009 15:47:26 -0700 (PDT) Sender: Thomas Anderson Received: by smtp.gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) gentoofan23@gentoo.org; Mon, 9 Mar 2009 18:47:26 -0400 (EDT) Date: Mon, 9 Mar 2009 18:47:25 -0400 From: Thomas Anderson To: gentoo-council@lists.gentoo.org Subject: [gentoo-council] Comparison of GLEP 54 and 'live ebuild' proposal Message-ID: <20090309224725.GA11724@dodo.hsd1.nj.comcast.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-council@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: b3296cb6-3ee4-4f52-aed3-6bfa837241cb X-Archives-Hash: 11449cea8ce386519af47e0e39621f4f --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Attached is my comparison of the two proposals for live sources. Sorry about getting it out late, I had to get ahold of a number of people to finish writing it up. Cheers, Thomas -- --------- Thomas Anderson Gentoo Developer ///////// Areas of responsibility: AMD64, Secretary to the Gentoo Council --------- --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="glep54comp.txt" GLEP54: This proposal attempts to have proper ordering with all version parts(0.2-scm should be higher than 0-2.1) while providing information to the package manager and user that this package should be treated like an ebuild with live sources. This proposal has the added advantage that it's already supported in at least one package manager so it's behaviour is defined and predictable. The only real objection to this proposal is that some don't like the version component name('scm'). No technical objections have been made, other than that it "doesn't go far enough". One thing immediately found lacking in this proposal is the lack of time of installation or the revision used. As stated in the GLEP however, this information can be exposed in other ways by the underlying scm tool. The specific revision however should not be in the package version but otherwise available. Live Ebuild: The liveebuild proposal attempts to give both proper ordering and an idea of point of time when the ebuild was installed, in other words, 'traceability' of live package. A keyword 'live' in the package version part of the filename is expanded to the ISO date(YYYYMMDD). One difference with GLEP54 is that while package managers supporting GLEP54 can on that information alone determine if a package is a live-sources package, with the live ebuild method one needs PROPERTIES=live as well(once the version is expanded one cannot know if it was a normal ebuild or a .live ebuild). A problem with liveebuild is that there has been no real specification other than the outline provided. A consequence is that there has not been consideration of what happens when you have two ebuilds: mythtv-0.20_prelive mythtv-0.20_pre20090309(today's date, which live would expand to) I've not seen any discussion or explanation of what would happen. This probably needs to be sorted out before this proposal can be accepted. This cannot be easily solved by saying "No two ebuilds in the same package can have the same version components because we never know what _live will expand to. One important issue is what happens in the following scenario: 1) world update starts at 20090301@2200hrs. 2) this particular update involves 100 packages so it takes quite along time 3) The _live package is not reached until 20090302 at 1AM. Is the package installed as 20090301 or 20090302? Similar to the above problem is what occurs when a user understandably puts =media-tv/mythtv-0.20_20090301 in package.{use,keywords} and the date changes. Also, what happens if the user =media-tv/mythtv-0.20.live in package.{use,keywords}? Is live expanded that early so it is invalid or is it still valid? --zhXaljGHf11kAtnf--