Re: [gentoo-dev] Revisions for USE flag changes

[Hans de Graaff]

On Fri, 2017-08-11 at 19:50 -0400, Michael Orlitzky wrote:
> 
> == New revisions for USE flag changes ==
> 
> I suggest that in hindsight, we can do better.

Not all IUSE changes are equal and thus a policy that treats them all
the same doesn't make sense to me. Maintainers are in a better position
to judge whether or not a new revision is needed. 

> == tl;dr ==
> 
> We would be better off with respect to IUSE changes and revisions if
> we
> deleted the --changed-use and --newuse flags right now, and just
> required developers to revbump when changing IUSE.

I don't see how these flags can be removed. You are describing a
policy, but this won't change the fact that IUSE changes are still
technically possible and will still happen, intentional or otherwise.

Hans

signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: Revisions for USE flag changes

[Michael Palimaka]

On 08/12/2017 09:50 AM, Michael Orlitzky wrote:
> Q. But what about the rebuilds?
> 
>   For most packages, the rebuilds simply don't matter. Unless you're
>   the maintainer of libreoffice, firefox, chromium, etc. -- just do the
>   revision and forget about the (quick) rebuilds.

I really wish people would stop trotting out this false argument. Not
everyone has the latest and greatest hardware. Rebuilds have a real cost
to end users and as such we should use them wisely.

>   We tell everyone to use --changed-use and --newuse if they want
>   things to work, so they were probably going to rebuild anyway.

Who tells everyone to use these flags and where? I never use these flags
day-to-day, only if I need that specific functionality for that reason

> Q. But what if I maintain firefox, and I need to change  IUSE?
> 
>   If the IUSE change isn't important, just make the new revision in a
>   branch and wait to commit it later when there are more changes
>   piled up. If it is important (like if its default value changes
>   RDEPEND), then it would have required a revision anyway.

Please stop trying to force workflows on people. Using that same logic,
I can make the IUSE change in-place and it would be propagated in the
next version bump.

> Q. But I work on a team, and we can't all work in different branches.
> 
>   If you work on a massive package and if you're collaborating with
>   others regularly, you can commit the new ebuild masked. This is
>   annoying, but is an extremely rare combination of circumstances.

Again, let's not try and tell teams which workflow works best for them.

> == tl;dr ==
> 
> We would be better off with respect to IUSE changes and revisions if we
> deleted the --changed-use and --newuse flags right now, and just
> required developers to revbump when changing IUSE.
> 
> Package managers get simpler, documentation gets simpler, the user
> interface gets simpler, and behavior becomes more uniform and predictable.
> 
> Please let me know what you think.

I disagree with this change because your proposed benefits don't hold up:

>   * We can delete all of the PM code for --changed-use and --newuse and
> friends.

As pointed out by Brian, we still need at least --changed-use even if
IUSE changes in-place are banned.

>   * The documentation becomes much simpler: revbump if IUSE changes.

We should base our policies around the cost / benefit of said policy,
not how many or few words we need to write in the devmanual about it.

>   * Users can omit --newuse and --changed-use from their lives.

They already can.

>   * All package managers now handle IUSE changes properly.

If you want to see consistent behaviour in how package manages handle
IUSE, I suggest sending patches for PMS. I don't see any problem in
portage/paludis/pkgcore handling things differently. That is the point
of having different package managers, after all.

>   * emerge runs a bit faster.

Why will it run faster?

Re: [gentoo-dev] Revisions for USE flag changes

[Brian Evans]

On 08/11/2017 08:59 PM, Michael Orlitzky wrote:
> On 08/11/2017 08:45 PM, Brian Evans wrote:
>>
>> I disagree about removing --newuse and --changed-use from portage.
>> This is not their only use.
>>
>> If you happen to change the effective use system wide, USE= in make.conf
>> for portage, these options scan the entire system for such changes.
>>
> 
> Does --changed-use help there? I can see the argument for --newuse, but
> I thought --changed-use only applied to flags that were added or removed
> to installed packages (which becomes impossible, if we require new
> revisions).
> 

--changed-use (-U)
   Tells emerge to include installed packages where USE flags have
   changed   since  installation.  This  option  also  implies  the
   --selective option. Unlike --newuse,  the  --changed-use  option
   does not trigger reinstallation when flags that the user has not
   enabled are added or removed.

The option is the same as --newuse except it ignores functionality that
you suggest to remove.  You could certainly deprecate one option or the
other if they became the same.  But the core functionality of
system-wide USE changes (by profile or user), needs to be scanned somehow.

Brian



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisions for USE flag changes

[Michael Orlitzky]

On 08/11/2017 08:59 PM, Michael Orlitzky wrote:
> 
> Does --changed-use help there? I can see the argument for --newuse, but
> I thought --changed-use only applied to flags that were added or removed
> to installed packages (which becomes impossible, if we require new
> revisions).
> 

^ this doesn't make any sense, I meant that the only difference between
--changed-use and --newuse is with regard to already-installed packages
that undergo an IUSE change.

Re: [gentoo-dev] Revisions for USE flag changes

[Michael Orlitzky]

On 08/11/2017 08:45 PM, Brian Evans wrote:
> 
> I disagree about removing --newuse and --changed-use from portage.
> This is not their only use.
> 
> If you happen to change the effective use system wide, USE= in make.conf
> for portage, these options scan the entire system for such changes.
> 

Does --changed-use help there? I can see the argument for --newuse, but
I thought --changed-use only applied to flags that were added or removed
to installed packages (which becomes impossible, if we require new
revisions).

Re: [gentoo-dev] Revisions for USE flag changes

[Brian Evans]

On 08/11/2017 07:50 PM, Michael Orlitzky wrote:
> == New revisions for USE flag changes ==
> 
> I suggest that in hindsight, we can do better. Suppose we require a new
> revision for every change to IUSE. Then,
> 
>   * We can delete all of the PM code for --changed-use and --newuse and
> friends.
> 
>   * The documentation becomes much simpler: revbump if IUSE changes.
> 
>   * Users can omit --newuse and --changed-use from their lives.
> 
>   * All package managers now handle IUSE changes properly.
> 
>   * emerge runs a bit faster.
> 
> This has none of the downsides of the current approach. Of course, it
> lacks that one benefit -- that you don't have to rename the ebuild when
> you change IUSE. Now I'll try to convince you that the rename and
> associated rebuilds aren't that big of a deal.

I disagree about removing --newuse and --changed-use from portage.
This is not their only use.

If you happen to change the effective use system wide, USE= in make.conf
for portage, these options scan the entire system for such changes.

i.e. 'emerge --changed-use --deep @world'

Brian



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New SYMLINK_LIB=no migration tool for review

[Gerogy Yakovlev]

Hi,

I was able to test this one a bit.
The test subjects were:
 ~amd64/openrc/desktop system which I was going to wipe anyway.
 amd64/openrc latest snapshot, updated to ~amd64 with boostrtap.sh

for the latter symlink migration was done before bootstrapping,


So far I found 3 issues so far:

1) kernel modules. modprobe looks into /lib/modules/$(uname -r), but
after running the tool they end up in /lib64/modules.

2) app-eselect/eselect-mesa  has some hardcoded paths:
MESA_CONF_DIR="${EROOT}/usr/share/mesa"
MESA_DIR_64="${EROOT}/usr/lib/mesa"
DRI_DIR_64="${EROOT}/usr/lib/dri"
MESA_DIR_32="${EROOT}/usr/lib32/mesa"
DRI_DIR_32="${EROOT}/usr/lib32/dri"
that leads to many funny breakages.

3) and minor one, sys-boot/refind will fails to build, because it looks
for 64bit libs in lib.


I'm going to play with the system next couple of weeks and If I find
anything else I'll let you know.


Regards,

Georgy Yakovlev.

On 08/02/2017 08:58 AM, Michał Górny wrote:
> Hi, everyone.
> 
> I've finally gotten around to writing a new tool for migrating amd64
> systems to SYMLINK_LIB=no layout [1]. I've put it in symlink-lib-
> migration [2] repository along with a README. Please review it and give
> it more testing.
> 
> The tool has a few advantages over the one attached to the bug. Most
> notably:
> 
> 1. It runs in three-stage semi-automatic mode. This gives the user
> an explicit opportunity to verify the action plan for any obvious
> mistakes, and to test a temporary 'lib.new' layout to confirm that
> the migration won't break anything before it's final.
> 
> 2. It supports a mid-migration rollback -- if 'lib.new' layout breaks
> stuff, the user runs './migrate.py --rollback' and he's back home.
> 
> 3. It works on top-directory level whenever possible. The stuff destined
> for /usr/lib is moved correctly along with any user-created files. When
> a top-directory is split between lib+lib64, all files except for those
> explicitly destined for lib64 land in lib (arbitrary decision).
> 
> 4. It does not reinvent the wheel poorly to copy files. Instead, it
> calls 'cp -a --reflink=auto ...' to guarantee that everything will be
> preserved correctly.
> 
> 5. It does not reinvent the wheel to parse vdb. Instead, it uses
> the Portage API to get installed file list. Portage is only required
> during the initial analysis phase, and the actual migration/rollback can
> be done without it (or with it being broken).
> 
> I've limited the scope of the tool to do the filesystem manipulation.
> Afterwards, it tells user to update the profile or adjust make.conf,
> and to rebuild all the packages.
> 
> What are your thoughts?
> 
> 
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=506276
> [2]:https://github.com/mgorny/symlink-lib-migration
> 

[gentoo-dev] Revisions for USE flag changes

[Michael Orlitzky]

We have a pull request for the devmanual that will update the revision
documentation; namely, when to create a new one:

  https://github.com/gentoo/devmanual.gentoo.org/pull/67

The comments bring up an issue that I think can benefit from some
hindsight. Specifically, the PR says that it's OK to change IUSE without
creating a revision, because users can use --changed-use to catch it.
My immediate objection to that was that --changed-use is specific to
Portage, but let's reflect on the status quo.


== The situation now ==

  1 We tell everyone to update with either --newuse or --changed-use.

  2 Developers change IUSE without new revisions.

  3 To facilitate (1) and (2), Portage has the --changed-use and
--newuse flags. Paludis has a family of "--keep" options to avoid
reinstallation, e.g. --keep=if-same-metadata. And pkgcore has its
own (different) --newuse flag.

  4 There is no specification for the features in (3), and each package
manager has taken a different approach.


The end result is that Portage users do see the changes made to IUSE
without a revision, but at a cost:

  * They have to pass the "required" --changed-use or --newuse flags to
every command.

  * The same cannot be said for users of other package managers.

  * Lots of PM code exists to handle this stuff.

  * Our documentation needs to describe the above (relatively)
complicated situation.


And with one notable benefit:

  * We don't need to rename the ebuild to change IUSE, and in theory we
can control when rebuilds happen.



== New revisions for USE flag changes ==

I suggest that in hindsight, we can do better. Suppose we require a new
revision for every change to IUSE. Then,

  * We can delete all of the PM code for --changed-use and --newuse and
friends.

  * The documentation becomes much simpler: revbump if IUSE changes.

  * Users can omit --newuse and --changed-use from their lives.

  * All package managers now handle IUSE changes properly.

  * emerge runs a bit faster.

This has none of the downsides of the current approach. Of course, it
lacks that one benefit -- that you don't have to rename the ebuild when
you change IUSE. Now I'll try to convince you that the rename and
associated rebuilds aren't that big of a deal.


Q. But what about the rebuilds?

  For most packages, the rebuilds simply don't matter. Unless you're
  the maintainer of libreoffice, firefox, chromium, etc. -- just do the
  revision and forget about the (quick) rebuilds.

  We tell everyone to use --changed-use and --newuse if they want
  things to work, so they were probably going to rebuild anyway.


Q. But what if I maintain firefox, and I need to change  IUSE?

  If the IUSE change isn't important, just make the new revision in a
  branch and wait to commit it later when there are more changes
  piled up. If it is important (like if its default value changes
  RDEPEND), then it would have required a revision anyway.


Q. But I work on a team, and we can't all work in different branches.

  If you work on a massive package and if you're collaborating with
  others regularly, you can commit the new ebuild masked. This is
  annoying, but is an extremely rare combination of circumstances.


== tl;dr ==

We would be better off with respect to IUSE changes and revisions if we
deleted the --changed-use and --newuse flags right now, and just
required developers to revbump when changing IUSE.

Package managers get simpler, documentation gets simpler, the user
interface gets simpler, and behavior becomes more uniform and predictable.

Please let me know what you think.

Re: [gentoo-dev] Packages up for grabs: app-forensics/* and other forensics@g.o packages

[Gordon Pettey]

I have used chkrootkit and rkhunter in the past. Will copy them to my
overlay (https://github.com/petteyg/gentoo-overlay) if they don't get a
maintainer.

On Fri, Aug 11, 2017 at 12:49 PM, RB  wrote:

> On Fri, Aug 11, 2017 at 11:40 AM, Michał Górny  wrote:
> > app-admin/integrit
> > app-forensics/afflib [o]
> > app-forensics/air
> > app-forensics/autopsy
> > app-forensics/chkrootkit [o]
> > app-forensics/cmospwd
> > app-forensics/examiner
> > app-forensics/galleta
> > app-forensics/libewf [o]
> > app-forensics/lynis
> > app-forensics/mac-robber
> > app-forensics/magicrescue
> > app-forensics/memdump
> > app-forensics/pasco
> > app-forensics/rifiuti [o]
> > app-forensics/rkhunter
> > app-forensics/scalpel [o]
> > app-forensics/sleuthkit [o]
> > net-mail/libpst [o]
> > sys-apps/dcfldd
> > sys-block/disktype
>
> The pentoo.ch overlay has superseded and expanded on a lot of these. I
> gave up on trying to provide patches and updates for this category
> long ago, but they have picked up the flag and are doing a good job.
>
>

Re: [gentoo-dev] Packages up for grabs: app-forensics/* and other forensics@g.o packages

[RB]

On Fri, Aug 11, 2017 at 11:40 AM, Michał Górny  wrote:
> app-admin/integrit
> app-forensics/afflib [o]
> app-forensics/air
> app-forensics/autopsy
> app-forensics/chkrootkit [o]
> app-forensics/cmospwd
> app-forensics/examiner
> app-forensics/galleta
> app-forensics/libewf [o]
> app-forensics/lynis
> app-forensics/mac-robber
> app-forensics/magicrescue
> app-forensics/memdump
> app-forensics/pasco
> app-forensics/rifiuti [o]
> app-forensics/rkhunter
> app-forensics/scalpel [o]
> app-forensics/sleuthkit [o]
> net-mail/libpst [o]
> sys-apps/dcfldd
> sys-block/disktype

The pentoo.ch overlay has superseded and expanded on a lot of these. I
gave up on trying to provide patches and updates for this category
long ago, but they have picked up the flag and are doing a good job.

[gentoo-dev] Packages up for grabs: app-forensics/* and other forensics@g.o packages

[Michał Górny]

Hi,

Due to the Forensics project [1] being disbanded, the following packages
are now up for grabs. Please note that some of the packages will
probably be taken by former project members.

app-admin/integrit
app-forensics/afflib [o]
app-forensics/air
app-forensics/autopsy
app-forensics/chkrootkit [o]
app-forensics/cmospwd
app-forensics/examiner
app-forensics/galleta
app-forensics/libewf [o]
app-forensics/lynis
app-forensics/mac-robber
app-forensics/magicrescue
app-forensics/memdump
app-forensics/pasco
app-forensics/rifiuti [o]
app-forensics/rkhunter
app-forensics/scalpel [o]
app-forensics/sleuthkit [o]
net-mail/libpst [o]
sys-apps/dcfldd
sys-block/disktype

The 6 packages marked [o] are outdated according to repology. Most of
the packages also have bugs open.

[1]:https://bugs.gentoo.org/626500

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Packages up for grabs: dev-vcs/*bzr*

[Michał Górny]

Hi, everyone.

Due to the Bazaar project being disbanded [1], the following packages
are up for grabs:

[n] dev-vcs/bzr-explorer
[o] dev-vcs/bzr-git
[n] dev-vcs/bzr-gtk
[o] dev-vcs/bzr-rewrite
[n] dev-vcs/bzr-xmloutput
[n] dev-vcs/bzr
[o] dev-vcs/bzrtools
[o] dev-vcs/qbzr

[n] -- newest/current, [o] -- outdated

According to repology, 4 of the packages are outdated. Furthermore,
there are a few minor bugs (QA-class) open for some of the packages.
Finally, the current version of bzr does not work at all [2], making
everything pretty much useless.

[1]:https://bugs.gentoo.org/626492
[2]:https://bugs.gentoo.org/627184

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] [PATCH 3/3] flag-o-matic.eclass: Strip LDFLAGS unsupported by the C compiler, #621274

[Michał Górny]

Include LDFLAGS in the variables stripped by strip-unsupported-flags.
The code reuses the current functions for testing CC, and so only remove
LDFLAGS that are rejected by the C compiler and not the linker. This
solves the case of bug #621274 where LDFLAGS contained GCC-specific
-flto flag.
---
 eclass/flag-o-matic.eclass   | 3 +++
 eclass/tests/flag-o-matic.sh | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index 79866e04a483..4e3cfff5afd5 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -546,6 +546,9 @@ strip-unsupported-flags() {
export CXXFLAGS=$(test-flags-CXX ${CXXFLAGS})
export FFLAGS=$(test-flags-F77 ${FFLAGS})
export FCFLAGS=$(test-flags-FC ${FCFLAGS})
+   # note: this does not verify the linker flags but it is enough
+   # to strip invalid C flags which are much more likely, #621274
+   export LDFLAGS=$(test-flags-CC ${LDFLAGS})
 }
 
 # @FUNCTION: get-flag
diff --git a/eclass/tests/flag-o-matic.sh b/eclass/tests/flag-o-matic.sh
index 5e7ee354bf33..53af9f862c41 100755
--- a/eclass/tests/flag-o-matic.sh
+++ b/eclass/tests/flag-o-matic.sh
@@ -55,7 +55,7 @@ done <<<"
 
 tbegin "strip-unsupported-flags"
 strip-unsupported-flags
-[[ ${CFLAGS} == "" ]] && [[ ${CXXFLAGS} == "-z=2" ]]
+[[ ${CFLAGS} == "" ]] && [[ ${CXXFLAGS} == "-z=2" ]] && [[ ${LDFLAGS} == "" ]]
 ftend
 
 for var in $(all-flag-vars) ; do
-- 
2.14.0

[gentoo-dev] [PATCH 2/3] flag-o-matic.eclass: test-flag-PROG, ignore unused args in clang

[Michał Górny]

By default, clang considers unused arguments as error when -Werror is
used. Since flag tests are performed without linking, this causes all
tests for linker flags to fail inadvertently and all those flags
are stripped as a result.

While the correctness of passing unused flags is doubtful, silently
stripping them in a few random packages is certainly not the solution
to the problem, and also makes the results differ between gcc and clang.
To account for that, use clang's -Qunused-arguments option to silence
unused argument warnings.

To avoid wasting time on testing the compiler, just try passing
-Qunused-arguments every time a flag check fails. If clang is not used,
the additional call will fail just the same as the previous one (either
because of the original flag or because of -Qunused-arguments), so
the result will be the same.
---
 eclass/flag-o-matic.eclass   | 9 -
 eclass/tests/flag-o-matic.sh | 5 +
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index 0393a30b74c3..79866e04a483 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -441,7 +441,14 @@ test-flag-PROG() {
cmdline+=( "${flag}" -c -o /dev/null /dev/null )
fi
 
-   "${cmdline[@]}" /dev/null
+   if ! "${cmdline[@]}" /dev/null; then
+   # -Werror makes clang bail out on unused arguments as well;
+   # try to add -Qunused-arguments to work-around that
+   # other compilers don't support it but then, it's failure like
+   # any other
+   cmdline+=( -Qunused-arguments )
+   "${cmdline[@]}" /dev/null
+   fi
 }
 
 # @FUNCTION: test-flag-CC
diff --git a/eclass/tests/flag-o-matic.sh b/eclass/tests/flag-o-matic.sh
index 92c68b82c3c9..5e7ee354bf33 100755
--- a/eclass/tests/flag-o-matic.sh
+++ b/eclass/tests/flag-o-matic.sh
@@ -143,6 +143,11 @@ tbegin "test-flags-CC (gcc-valid but clang-invalid flags)"
 out=$(CC=clang test-flags-CC -finline-limit=1200)
 [[ $? -ne 0 && -z ${out} ]]
 ftend
+
+tbegin "test-flags-CC (unused flags w/clang)"
+out=$(CC=clang test-flags-CC -Wl,-O1)
+[[ $? -eq 0 && ${out} == "-Wl,-O1" ]]
+ftend
 fi
 
 texit
-- 
2.14.0

[gentoo-dev] [PATCH 1/3] flag-o-matic.eclass: test-flag-PROG, refactor to reduce duplication

[Michał Górny]

---
 eclass/flag-o-matic.eclass | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index b2f3742b3ecf..0393a30b74c3 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -433,11 +433,15 @@ test-flag-PROG() {
# Use -c so we can test the assembler as well.
-c -o /dev/null
)
-   if "${cmdline[@]}" -x${lang} - /dev/null 2>&1 ; then
-   "${cmdline[@]}" "${flag}" -x${lang} - /dev/null 2>&1
+   if "${cmdline[@]}" -x${lang} - /dev/null ; then
+   cmdline+=( "${flag}" -x${lang} - )
else
-   "${cmdline[@]}" "${flag}" -c -o /dev/null /dev/null >/dev/null 
2>&1
+   # XXX: what's the purpose of this? does it even work with
+   # any compiler?
+   cmdline+=( "${flag}" -c -o /dev/null /dev/null )
fi
+
+   "${cmdline[@]}" /dev/null
 }
 
 # @FUNCTION: test-flag-CC
-- 
2.14.0

[gentoo-dev] [PATCH] flag-o-matic.eclass: LDFLAGS stripping, take two

[Michał Górny]

Hi, everyone.

I've just reverted the LDFLAGS stripping code I've committed earlier
because it failed hard with clang. Here's an updated patch set that
ensures that clang is going to work fine. Please review.

--
Best regards,
Michał Górny

[gentoo-dev] Re: Gentoo QA Help

[Michael Palimaka]

On 08/11/2017 12:30 AM, Michael Mair-Keimberger wrote:
> Hi Gentoo Team,
> 
> As some of you may noticed i started to clean up some old patches in the
> gentoo portage tree. I did so already a while ago, and like before I'm
> using a small script in order to identify unused patches.

I just wanted to say thank-you for all your work on this. I certainly
appreciate how much cleaner the tree is from your 1000+ commits, and I'm
sure others do to.

[gentoo-dev] Re: [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc

[Duncan]

Sergei Trofimovich posted on Fri, 11 Aug 2017 09:14:42 +0100 as excerpted:

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

Just saying interesting it's the same lib and apparently the same 
symlinking logic and line involved, and while it doesn't seem to be the 
same bug, it might be worth a bit of extra care while fixing the one to 
keep in mind the other so as not to further complicate fixing it, is all.

(I'll be working on my bug either late today/Friday or Saturday.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc

[Sergei Trofimovich]

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

> Sergei Trofimovich posted on Tue, 08 Aug 2017 16:53:22 +0100 as excerpted:
> 
> > The failure happens when live glibc- ebuild is installed:
> >  * QA Notice: Missing gen_usr_ldscript for libm-2.26.90.so * ERROR:
> >  sys-libs/glibc-::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-.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


pgpra59rUdSNs.pgp
Description: Цифровая подпись OpenPGP