Drop cvs expanded keywords from files in the portage tree. AFAIK there are not used for anything usefull and make `repoman commit` do two commits in order to commit an ebuild change, which causes issues (see SeeAlso). Reproducible: Always
(In reply to Jan Matějka from comment #0) > AFAIK there are not used for anything usefull The only objection that I've heard was from Fabian Groffen since he's been using it in the gentoo-prefix sync script: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg55242.html
yup, still do
Then please fix your scripts not to depend on the keywords.
(In reply to Jan Matějka from comment #3) > Then please fix your scripts not to depend on the keywords. I guess you have no clue what you're talking about.
I guess the prefix script compares the $Header revision to the copy of ebuild that has been previously synced? Wouldn't it be possible to use digests or st_mtime instead?
git doesn't track modification times (:() Turning it the other way around: what is so important that we have to rush on removing keywords now, that I have to find all kinds of workarounds and hacks to keep some ebuilds synchronised for as long as we don't use a git main tree? (AFAICT there is no such thing in the foreseeable future). I'd love to not block you on this point, as much as I'd love not to have an overlay to keep in sync. Unless I'm seriously impeding some other important and progressive changes, I kindly request to keep things as is. Let me remind you that CVS commits are not atomic on global level, but per-file. So even though you would avoid a "double commit", you're still not atomic, e.g. allowing a gap.
(In reply to Jan Matějka from comment #3) > Then please fix your scripts not to depend on the keywords. We just need to merge the remaining 130 packages from the prefix overlay back into gx86, then the keywords can go ;-) (see bug #315803 for the progress)
(In reply to Fabian Groffen from comment #6) > Let me remind you that CVS commits are not atomic on global level, but > per-file. So even though you would avoid a "double commit", you're still > not atomic, e.g. allowing a gap. There is problem specificaly with "double commit" as reported in bug #298605 > Turning it the other way around: what is so important that we have to rush > on removing keywords now, When I asked around why don't we just drop the keywords expansion, I got a reply like "one or two devs don't feel like it", so I wanted to get a rationale or at least to get this on record.
The thing is, that people are coming up with unreliable shenanigans to solve bug #298605. Well, besides mgorny whose solution seems quite clever, but still that solution adds code while this one would not (if not also remove some).
This is broken for us for years, but we're coping with it. In the current state of things, it's better this way, no need to consider anything for this.
