| 1 |
Zac Medico posted <43A48014.1080000@×××××.com>, excerpted below, on Sat, |
| 2 |
17 Dec 2005 13:16:04 -0800: |
| 3 |
|
| 4 |
> Off hand, perhaps portageq could provide a query that |
| 5 |
> returns some type of UUID for a package, such as a hash of the ebuild. |
| 6 |
> That way, the hash from /var/db/pkg could be compared to the hash from the |
| 7 |
> repo that has the news item. If the hashes don't match, then the news |
| 8 |
> item is irrelevant. |
| 9 |
|
| 10 |
Ebuild hashes certainly would /not/ work, because existing ebuilds are |
| 11 |
routinely changed (thereby changing the hash) after initial appearance in |
| 12 |
the tree, while keeping the same ebuild -rX number (thus, the same |
| 13 |
filename, the same ebuild). Policy (as understood here, noting that I'm |
| 14 |
not a dev) is that the revision can remain the same if it's not something |
| 15 |
that's going to majorly effect users who have already merged the existing |
| 16 |
version. Thus, for example, changes to the ebuild that only fix bugs that |
| 17 |
kept it from building on specific system configurations don't warrant a |
| 18 |
revision bump, because that doesn't affect those who /were/ able to merge |
| 19 |
it. Creating a revision bump in that case simply forces them to do more |
| 20 |
unnecessary updating (assuming they keep reasonably updated in the first |
| 21 |
place). Of course, a security revision or patch that adds functionality |
| 22 |
for existing users, should normally get a -rX bump, while upstream bumps |
| 23 |
of course correspond to bumps as well. |
| 24 |
|
| 25 |
Brian's comment that news should be repository specific makes the most |
| 26 |
sense to me, thereby eliminating the need for ebuild UUIDs for the |
| 27 |
purposes of news, anyway. However, were they to be needed, they would |
| 28 |
almost certainly be implemented as yet another variable in the ebuild, as |
| 29 |
that would at once separate ebuild changes from UUID changes, and be |
| 30 |
relatively simple to implement, given the number of other variables |
| 31 |
already parsed. |
| 32 |
|
| 33 |
-- |
| 34 |
Duncan - List replies preferred. No HTML msgs. |
| 35 |
"Every nonfree program has a lord, a master -- |
| 36 |
and if you use the program, he is your master." Richard Stallman in |
| 37 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 38 |
|
| 39 |
|
| 40 |
-- |
| 41 |
gentoo-dev@g.o mailing list |
Archives