I like to use symlinks in repos, mostly for latest revision linked to live ebuild. Actual code in 9999 ebuild, an latest version symlinks to that. I have noticed if I do type changes in git, repoman does not respect this. It leaves a file uncommitted. I would assume repoman would add all files that were added via git add . but that is not the case. I have to run git commit --amend to add the file repoman missed. Easier to show than say. $ git add . $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) typechange: jclouds-drivers-jsch-1.9.2.ebuild copied: jclouds-drivers-jsch-1.9.2.ebuild -> jclouds-drivers-jsch-9999.ebuild $ repoman commit RepoMan scours the neighborhood... >>> Creating Manifest for /usr/portage/local/os-xtoo/dev-java/jclouds-drivers-jsch Note: use --include-dev (-d) to check dependencies for 'dev' profiles * 1 files being committed... [master 0a81c74] dev-java/jclouds-drivers-jsch: Added live version 1 file changed, 51 insertions(+) create mode 100644 dev-java/jclouds-drivers-jsch/jclouds-drivers-jsch-9999.ebuild Commit complete. RepoMan sez: "If everyone were like you, I'd be out of business!" $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) typechange: jclouds-drivers-jsch-1.9.2.ebuild $ git commit --amend [master 0867bdd] dev-java/jclouds-drivers-jsch: Added live version Date: Mon Nov 7 20:40:48 2016 -0500 2 files changed, 18 insertions(+), 48 deletions(-) rewrite dev-java/jclouds-drivers-jsch/jclouds-drivers-jsch-1.9.2.ebuild (100%) mode change 100644 => 120000 copy dev-java/jclouds-drivers-jsch/{jclouds-drivers-jsch-1.9.2.ebuild => jclouds-drivers-jsch-9999.ebuild} (67%)
Since repoman doesn't do any lstat calls, I suspect parsing of git output inside repoman/pym/repoman/modules/vcs/git/changes.py might be a contributor.
Symlinks are banned from the gentoo tree, as discussed here: http://gentoo.2317880.n4.nabble.com/symlinks-in-the-tree-td301142.html We might use a metadata/layout.conf setting to control whether or not symlinks are allowed.
I am not surprised by the comments in that post. I disagree with many things with the current status quo in Gentoo. Most that commented I disagree with on other non technical things. Easy to see how approaches and pros/cons can vary. Thanks for pointing out that post. I was unware the topic came up. I was considering a similar one and had not searched archives. It does not seem like many commented on that. Did the council take a stance one way or another? Repoman surely does not ban use of symlinks, no warnings, it commits them just not type changes. I would question running Gentoo on a filesystem that did not support symlinks. I think quite many ebuilds create symlinks. How can portage not use something ebuilds are creating. Seems neither would work on a filesystem that did not support it. NOt sure how valid of an argument that is, and it is the strongest one. Now with regard to stabilization, that would be a case for making a copy of the ebuild. However it could also be handled with a conditional in the ebuild. There are simply to many cases where ebuilds are literally copied for a version bump. The contents does not change at all. At the same time, you could apply a fix to on that may be required on several and making it to a file that is symlinked can make that easier. Like live ebuild always being real, ~arch always being a symlink, and if needed can copy to a file for stable arch. While it may not reduce size of git. It could substantially reduce the size of the portage tree. It can always help with cleanup as there would be less copies around. At the same time, if the ebuild has not changed, you could have many versions kept around as they are just symlinks and not much overhead. I use them in my repo and do not have any plans to stop using them as I see far to many benefits. More so when managing large amounts of ebuilds, it is a major time saver. For any package I have at least 1 less ebuild to maintain or modify. If repoman wants to address that it would be cool. Its a one off scenario when you change an actual file to a symlink. Even that is pretty rare as I am getting more in the habit of doing the symlink stuff by default. repoman respects symlinks otherwise, just has issues with type changes, file changed to a symlink of the same name.
Repoman can have things configured per repo. In fact more things will become configurable with the stage3 of the re-write. The git module was just not checking for or tracking any "T" type changes. I've already started some code to add that capability. I will most likely have the option defaulted to not allow symlinks, but a simple layout.conf option should be all that will be needed to allow them.
Configurable per repo sounds great thanks! This is a pretty rare scenario, thank you for addressing in repoman!
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
