| 1 |
Steve Long wrote: |
| 2 |
> Danny van Dyk wrote: |
| 3 |
>>> In practice I find it's rare that a user has been hacking around in |
| 4 |
>>> the eclasses. All the SHA1 tells you is that it's not the most |
| 5 |
>>> recent, but it's not easy to determine from the SHA1 exactly which |
| 6 |
>>> version they do have (so it's not enough to determine what's |
| 7 |
>>> different). |
| 8 |
>>> |
| 9 |
>>> Having said that, the most accurate way to find out what they have is |
| 10 |
>>> to get them to attach the eclass and diff it yourself. However |
| 11 |
>>> relying on the SHA1 also means you can't just say things like, "Check |
| 12 |
>>> eclass <blah> is version 1.836 (look at the "$Header" line at the top |
| 13 |
>>> of the file)." |
| 14 |
>> In the case of GIT you can just use 'git diff SHA1SUM' to see what has |
| 15 |
>> changed or 'git log SHA1SUM..HEAD' to show a list of revisions in |
| 16 |
>> between. So _if_ we changed to git, this would be no problem as long as |
| 17 |
>> every user has sha1sum installed [which is part of coreutils]. |
| 18 |
>> |
| 19 |
> Well since that appears to be some way off, is there any way to get the |
| 20 |
> needed functionality (version string inside ebuild) without a double |
| 21 |
> commit? (Did i read that right?) I'm thinking at worst someone might have |
| 22 |
> to add something to repoman, or a hook on the server end. |
| 23 |
> |
| 24 |
Not really, the Manifest needs to checksum the ebuild, and the ebuild |
| 25 |
will be updated as it is commited. A server side hook would at a |
| 26 |
minimum be able to checksum files and generate manifest entries; I doubt |
| 27 |
it's even possible to do though (most pre-commit scripts don't let you |
| 28 |
touch the files being commited, although I'm no expert on CVS). |
| 29 |
|
| 30 |
Current Scenario: |
| 31 |
|
| 32 |
Commit Ebuild |
| 33 |
Checksum ebuild |
| 34 |
Commit Manifest |
| 35 |
|
| 36 |
The worst part is that for those crazy people who want the entire tree |
| 37 |
signed: |
| 38 |
|
| 39 |
Commit ebuild |
| 40 |
Checksum ebuild |
| 41 |
Commit Package Manifest |
| 42 |
Checksum Package Manifest |
| 43 |
Commit Category Manifest |
| 44 |
Checksum Category Manifest |
| 45 |
Commit Tree-wide Manifest |
| 46 |
Checksum Tree-Wide Manifest and put it somewhere as a verification of |
| 47 |
the entire tree at time T. |
| 48 |
|
| 49 |
Notice now there are 4 commits instead of two, because each commit in |
| 50 |
sequence requires the $header$ to be updated (which in itself requires a |
| 51 |
commit). Yay! |
| 52 |
|
| 53 |
-Alec |
| 54 |
-- |
| 55 |
gentoo-dev@g.o mailing list |
Archives