From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1Enxf7-0008Ut-Vd for garchives@archives.gentoo.org; Sun, 18 Dec 2005 12:29:14 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBICSVSK031559; Sun, 18 Dec 2005 12:28:31 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBICQihO017398 for ; Sun, 18 Dec 2005 12:26:44 GMT Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by smtp.gentoo.org with esmtp (Exim 4.54) id 1Enxch-0001y4-I8 for gentoo-dev@lists.gentoo.org; Sun, 18 Dec 2005 12:26:43 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Enxb9-0000SZ-6W for gentoo-dev@gentoo.org; Sun, 18 Dec 2005 13:25:07 +0100 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Dec 2005 13:25:06 +0100 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Dec 2005 13:25:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Multiple Repo Support Date: Sun, 18 Dec 2005 05:24:44 -0700 Organization: Sometimes Message-ID: References: <43A235AD.6030604@leetworks.com> <20051216035630.2b005138@snowdrop.home> <20051216121208.GD30053@nightcrawler.e-centre.net> <20051216175817.65682c34@snowdrop.home> <43A32F35.1020803@gmail.com> <20051216213353.5488df83@snowdrop.home> <43A33CE9.4090407@gmail.com> <20051216222705.62485e5c@snowdrop.home> <43A367C0.2040200@gmail.com> <43A47740.5040107@gmail.com> <20051217205039.04178471@snowdrop.home> <43A48014.1080000@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=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: 66acbd38-f7e3-4cd3-9cae-58ee382e97b4 X-Archives-Hash: 7a38fa5c99e1b658b55e139e4cdfbaf4 Zac Medico posted <43A48014.1080000@gmail.com>, excerpted below, on Sat, 17 Dec 2005 13:16:04 -0800: > Off hand, perhaps portageq could provide a query that > returns some type of UUID for a package, such as a hash of the ebuild. > That way, the hash from /var/db/pkg could be compared to the hash from the > repo that has the news item. If the hashes don't match, then the news > item is irrelevant. Ebuild hashes certainly would /not/ work, because existing ebuilds are routinely changed (thereby changing the hash) after initial appearance in the tree, while keeping the same ebuild -rX number (thus, the same filename, the same ebuild). Policy (as understood here, noting that I'm not a dev) is that the revision can remain the same if it's not something that's going to majorly effect users who have already merged the existing version. Thus, for example, changes to the ebuild that only fix bugs that kept it from building on specific system configurations don't warrant a revision bump, because that doesn't affect those who /were/ able to merge it. Creating a revision bump in that case simply forces them to do more unnecessary updating (assuming they keep reasonably updated in the first place). Of course, a security revision or patch that adds functionality for existing users, should normally get a -rX bump, while upstream bumps of course correspond to bumps as well. Brian's comment that news should be repository specific makes the most sense to me, thereby eliminating the need for ebuild UUIDs for the purposes of news, anyway. However, were they to be needed, they would almost certainly be implemented as yet another variable in the ebuild, as that would at once separate ebuild changes from UUID changes, and be relatively simple to implement, given the number of other variables already parsed. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list