On Thu, 10 Aug 2017 21:41:24 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Sergei Trofimovich posted on Tue, 08 Aug 2017 16:53:22 +0100 as excerpted:
> 
> > The failure happens when live glibc-9999 ebuild is installed:
> >  * QA Notice: Missing gen_usr_ldscript for libm-2.26.90.so * ERROR:
> >  sys-libs/glibc-9999::gentoo failed:
> >  *   add those ldscripts
> > 
> > The problem here is how upstream glibc version is detected:
> >     dosym ../../$(get_libdir)/libm-${PV}.so
> >     $(alt_usrlibdir)/libm-${PV}.so
> > 
> > Change to use 'version.h' to pick upstream version.  
> 
> Interesting that it's libm.  See bug #627378
> 
> https://bugs.gentoo.org/627378
> 
> ... where ~arch glibc-2.25-r2 (apparently) allows the symlink creation 
> line above to clobber the original library binary, in usr merge (/lib64 
> and /usr/lib64 are the same dir) cases, or at least when /usr -> . (aka 
> "reverse" usr merge).
> 
> Comment #4 says it's not new code, thus the "(apparently)" above

What is your point there? I'm afraid I lost you.

(being an eclass) All the glibc ebuilds do this same libm symlinking.
Live ebuild was broken for quite a while because upstream
never installed libm-9999.a files.

> but 
> perhaps it's acting differently now due to the recent migration away from 
> eblits?  What I know for sure is that the upgrade broke my system until I 
> manually copied the libm binary from the binpkg back into place.

You can check if it's a new breakage by setting up a chroot:
- with your '/usr -> .' symlinks set
- with pre-eblits glibc portage tree by rewinding git ::gentoo
- install any glibc version from there to chech if the breakage is new

I suspect it's not a new breakage. Because glibc does not check
symlink state on a live system (and it should not). portage does peform
merge into live system phase and writes two files into the same path.

portage would be a better place to detect symlink collision and save your system.

I think this discussion belongs to https://bugs.gentoo.org/627378

-- 

  Sergei