I hope you are able to unterstand what I wish to say. If not, perhabs you can test what I have done. First of all, I do not know if this is a feature or a bug. So please be patiant. I have had a problem with an ebuild and I noticed, that the "doins" function do not what it have done in older portage versions. So I have done a few tests, to analyze my assumption. In short: "doins -r ${FOLDER}/" failed, if ${FOLDER} is a symlink to another folder. Steps to reproduce the problem: emerge -1 =app-shells/bash-3.2_p33 emerge -1 =sys-apps/portage-2.1.4.4 emerge -1 =games-sports/stormbaancoureur-2.1.5 (all is okay) emerge -1 =sys-apps/portage-2.1.5.6 emerge -1 =games-sports/stormbaancoureur-2.1.5 (files are missing) In long: Because my complete system is set to ~x86 I have to do the following to test a stable portage version: I have to install a stable bash version: emerge -1 =app-shells/bash-3.2_p33 Install the stable portage version emerge -1 =sys-apps/portage-2.1.4.4 Rebuild ebuild that showed me the new behaviour emerge -1 =games-sports/stormbaancoureur-2.1.5 All is okay, the data files under '/usr/share/games/stormbaancoureur' are installed. So, to preclude that the version of bash is responsible for the problem I only changed the portage version. Installed the next available version (testing now): emerge -1 =sys-apps/portage-2.1.5.6 Rebuild ebuild that showed me the new behaviour emerge -1 =games-sports/stormbaancoureur-2.1.5 So, there are _no_ data files under '/usr/share/games/stormbaancoureur' installed. Here the extract from the 'src_install()' output: >>> Install stormbaancoureur-2.1.5 into /var/tmp/portage/games-sports/stormbaancoureur-2.1.5/image/ category games-sports cp: omitting directory `images' install: cannot stat `/var/tmp/portage/games-sports/stormbaancoureur-2.1.5/temp/images': No such file or directory cp: omitting directory `models' install: cannot stat `/var/tmp/portage/games-sports/stormbaancoureur-2.1.5/temp/models': No such file or directory cp: omitting directory `sounds' install: cannot stat `/var/tmp/portage/games-sports/stormbaancoureur-2.1.5/temp/sounds': No such file or directory cp: omitting directory `shaders' install: cannot stat `/var/tmp/portage/games-sports/stormbaancoureur-2.1.5/temp/shaders': No such file or directory >>> Completed installing stormbaancoureur-2.1.5 into /var/tmp/portage/games-sports/stormbaancoureur-2.1.5/image/ Because the bash version was the same and only the portage version was changed, portage must be responsible for that. Reproducible: Always Steps to Reproduce: See above (in short)
I guess the difference in behavior was probably introduced by the changes from bug #210575. I'll see about changing it back.
Created attachment 167242 [details, diff] fix cases where arguments are symlinks to directories If this patch is saved as /tmp/doins_sym.patch, then it can be applied as follows: patch /usr/lib/portage/bin/doins /tmp/doins_sym.patch
The patch fixed the problem. Thanks! Can you have a look at: http://bugs.gentoo.org/show_bug.cgi?id=239128 I am not sure, if this bug should depend on the other bug or the other bug should depent on this bug.
Oh, sorry, I answered to fast. The files are installed - okay. But the name of the directory is wrong folder 'b' is a symbolic link to folder 'a' b -> a After a "doins -r b/" the folder 'b' should be installed and the name for the folder should be 'b'. In your patch, the name 'a' is used.
Created attachment 167312 [details, diff] fix cases where arguments are symlinks to directories (In reply to comment #3) > Can you have a look at: > http://bugs.gentoo.org/show_bug.cgi?id=239128 > > I am not sure, if > this bug should depend on the other bug > or > the other bug should depent on this bug. > It's really a duplicate of this bug. You can reopen it and mark it as such.
*** Bug 239128 has been marked as a duplicate of this bug. ***
This seems okay now, thanks again. Today I have no time to have a clearer look at the patch, but in the next day... Perhaps the usage of 'mktemp' for .doins_tmp is better. But you will surely know it better.
This is fixed in 2.2_rc12. (In reply to comment #7) > This seems okay now, thanks again. Thanks for testing. > Today I have no time to have a clearer look at the patch, but in the next > day... > Perhaps the usage of 'mktemp' for .doins_tmp is better. But you will surely > know it better. Well, there's practically zero chance of a name collision here so mktemp shouldn't be necessary. Also, we try to avoid dependencies on random binaries like that. I suppose we can probably rely on mktemp being available though, but still, it's not really needed.
