Presumably due to the recent (ongoing?) git migration, all of the version tags in all ebuilds and files have been replaced with '$Id$' when fetched via rsync with 'emerge --sync'. e.g. $ head -n 5 sys-apps/portage/portage-2.2.20.1.ebuild # Copyright 1999-2015 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$ EAPI=5 Whilst many users may not care, this makes it much more difficult to tell whether a change has been made to an ebuild without a version-bump - and in my specific case, I maintain an overlay repo which attempts to track upstream, and this has removed my ability to (again, easily) tell if a minor update has been made to an ebuild I've overlaid. It sounds as if this is an unintended change - or, at least, that the IDs are supposed to be replaced/regenerated from git before the files are retrieved by rsync, and this new mechanism is not currently working.
I believe the infra team is working on getting $Id$ replacement working.
Reading into it a little more, is the fix from the git side of things to simply add a root-level '.gitattributes' file to the Gentoo Portage tree containing: /*-*/*/*.ebuild ident /*-*/*/files/** ident /*-*/*/ChangeLog* ident ... or similar? If the git repo is then pulled onto rsync mirrors, they should then automagically get the version-substituted copy of the repo data? The danger seems to be that the '$Id: .*$' <=> '$Id$' transformation could unintentionally affect patches or binaries if this sequence happens to appear... there seems to be no obvious way to only apply this substitution to the file header, or line 3, etc. :( (Presumably a git hook could be used to look for '$Id$' appearing anywhere *other* than the third line of a file and reject the commit if so? A local .gitattributes file in the same directory could then be used to prevent the transformation from occuring)
The issue of whether or not to remove the $Id$ headers has come up again. How exactly are you using them to indicate whether or not an ebuild has changed? There might be a better way that both saves you time and lets us get rid of the $Id$ at the top of every ebuild. Any details you can give will help us brainstorm.
(In reply to Michael Orlitzky from comment #3) > The issue of whether or not to remove the $Id$ headers has come up again. > How exactly are you using them to indicate whether or not an ebuild has > changed? There might be a better way that both saves you time and lets us > get rid of the $Id$ at the top of every ebuild. Any details you can give > will help us brainstorm. @mjo: If the $Id$ is expanded on export, and the file is later modified, you can use the expanded $Id$ to see what has changed (since it allows you to recover the unmodified blob representing the exact file in question, without any knowledge of the path). The older CVS $Header$ allowed exact recovery of the unmodified file content but explicitly included the path & revision to handle that.
I stopped using rsync because of exactly this problem - I now use git with an expanded version of .gitattributes similar to (but more comprehensive than) that proposed above, a sub-repo for metadata/news, and post-sync runs of egencache to rebuild other missing metadata. So far, I think this covers everything - but it's obviously much more involved than simply being able to pull all of this data via rsync as before. What this gives me is files with $Id$ expanded to deterministic hashes - so by using these values as references I can tell whether the base Gentoo ebuild files have been update w.r.t. the modified ebuilds I maintain in my local repo (github.com/srcshelton/gentoo-ebuilds), and allows me to ensure that I can track any changes (such as keyword changes) which done involve a revision-bump.
(In reply to Stuart Shelton from comment #5) > I stopped using rsync because of exactly this problem - I now use git with > an expanded version of .gitattributes similar to (but more comprehensive > than) Can you share your expanded .gitattributes file then? >that proposed above, a sub-repo for metadata/news, and post-sync runs > of egencache to rebuild other missing metadata. You might be interested in https://github.com/hasufell/portage-gentoo-git-config
Sure, FWIW this is what I'm currently using: /*-*/*/*.ebuild ident /*-*/*/files/** ident /eclass/*.eclass ident /eclass/tests/*.sh ident /profiles/license_groups ident /profiles/**/README ident profiles/**/make.defaults ident profiles/**/packages ident profiles/**/packages.build ident profiles/**/package.mask ident profiles/**/package.provided ident profiles/**/package.unmask ident profiles/**/package.use ident profiles/**/package.use.force ident profiles/**/package.use.mask ident profiles/**/package.use.stable.force ident profiles/**/package.use.stable.mask ident profiles/**/profile.bashrc ident profiles/**/use.force ident profiles/**/use.mask ident profiles/**/use.stable.force ident profiles/**/use.stable.mask ident ... I'm open to suggestions for anything I've missed or any optimisations ;)
The postsync.d stuff I like - I'll integrate that this evening. Thanks!
(In reply to Stuart Shelton from comment #5) > > What this gives me is files with $Id$ expanded to deterministic hashes - so > by using these values as references I can tell whether the base Gentoo > ebuild files have been update w.r.t. the modified ebuilds I maintain in my > local repo (github.com/srcshelton/gentoo-ebuilds), and allows me to ensure > that I can track any changes (such as keyword changes) which done involve a > revision-bump. Ok, I think I understand now. You've got your own overlay with modified copies of ebuilds that are already in the ::gentoo tree: you don't want to know if your copies differ from the upstream ones (they always do) -- you want to know when the upstream ebuilds have been modified from their previous upstream version. My first instinct is that it would be easier to do that with a git branch than an overlay. Pulling down the changes would be as simple as merging master into your branch, and you wouldn't have to worry about what changed unless there was a conflict. But that also has downsides; your "overlay" tree will have a million packages in it instead of only the modified ones, and I don't know how the metadata would work. I'll ponder it for a bit.
Is there still anything to be done here? I forgot all about this, and I would imagine that no one is still trying to work around the absence of CVS tags five years later.
(In reply to Michael Orlitzky from comment #10) > Is there still anything to be done here? I forgot all about this, and I > would imagine that no one is still trying to work around the absence of CVS > tags five years later. Still maintaining the overlay and tracking upstream ebuild changes! The scripts which handle this have been extensively refactored to work from git commit IDs and diffs, though. I guess you could reasonably suggest that since the '$Id' field has been removed entirely, the issue of unexpanded '$Id' placeholders appearing in ebuild files is unquestionably resolved ;)
