Zac Medico posted <[EMAIL PROTECTED]>, 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
