Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
New profiles 17.1
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3, 4  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
charles17
Advocate
Advocate


Joined: 02 Mar 2008
Posts: 3431

PostPosted: Fri Dec 22, 2017 10:18 pm    Post subject: New profiles 17.1 Reply with quote

First (experimental) 17.1 profiles news item for review (v2) https://archives.gentoo.org/gentoo-dev/message/cc9cd23b9f3a1776ddf258bb6f6cb751 wrote:
2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib'

3. Run 'unsymlink-lib --analyze' and check the output for obvious
    mistakes
. If you need to perform any changes to the system, remember
    to run 'unsymlink-lib --analyze' again afterwards.

But how to see there were such obvious mistakes? The output doesn't tell me very much:

unsymlink-lib --analyze:
Analyzing files installed into lib & lib64...

pure /lib/:
   gentoo
   modprobe.d
   firmware
   udev
   (+ 0 files)

split /lib/+/lib64/:
   dhcpcd

unowned files for /lib/:
   modules
   cpp

pure /usr/lib/:
   portage
   gcc
   clang
   llvm
   geeqie
   tmpfiles.d
   jvm
   python-exec
   systemd
   crda
   (+ 0 files)

split /usr/lib/+/usr/lib64/:
   misc

unowned files for /usr/lib/:
   nsbrowser
   cracklib_dict.pwi
   python3.4
   cracklib_dict.pwd
   libsoftokn3.chk
   cracklib_dict.hwm
   lua
   help2man
   libfreebl3.chk
   pcmanfm
   libnssdbm3.chk
   libxslt-plugins

unowned files for /usr/lib64/:
   libdb_stl.a
   libdb_cxx.a
   libdb_cxx.so
   libcblas.a
   libcblas.so.0
   libcblas.so
   libdb_stl.so
   libdb.a
   libdb.so
   libdb_sql.so
   libdb_sql.a

pure /usr/local/lib/:
   (+ 0 files)

split /usr/local/lib/+/usr/local/lib64/:

The state has been saved and the migration is ready to proceed.
To initiate it, please run:

   /usr/lib/python-exec/python3.5/unsymlink-lib --migrate

Please do not perform any changes to the system at this point.
If you performed any changes, please rerun the analysis.

Edit: Link updated (v2)


Last edited by charles17 on Sat Dec 23, 2017 6:39 am; edited 2 times in total
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3850
Location: Illinois, USA

PostPosted: Sat Dec 23, 2017 12:25 am    Post subject: Reply with quote

Ugh! More fixing what wasn't broken.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7428

PostPosted: Sat Dec 23, 2017 1:01 am    Post subject: Reply with quote

no, it's more fixing what they have broken :)

/lib->/lib64 mean anything trying to run from /lib will seek files in /lib64, and the /lib32 concept is horribly broken.

While your own system can dispatch what you are building thru /lib64 /lib32 as need, the game change for 32 binaries packages.
Native 32bits system use /lib not /lib32 and expect to find 32bits libs and executable from /lib and never from /lib32

So running such program, it will have its dependencies link to /lib: making your multilib 64bits/32bits system unable to run it finally.
Look at the broken concept of both /lib as symlink and /lib32
/lib32/ld-linux.so.2 : any binaries 32bits program will aim for /lib/ld-linux.so.2 and will be broken because your system have it in /lib32, and it will seek it in /lib64 (because of the symlink)

So /lib32 is broken concept because native 32bits will seek /lib and never /lib32

And /lib itself should always have native libraries support for booting program: it mean all programs from /sbin and /bin
It mean that /lib64 itself should hold 64bits if you want, but nothing critical to boot, allowing even if you want /lib64 to be on another disk or partition, or read-only.
But the symlink compatibility has made bad result as everything is link against /lib64 and not /lib like they should
Code:
ldd /bin/dmesg
   linux-vdso.so.1 (0x00007fff5c184000)
   libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f8f9be32000)
   librt.so.1 => /lib64/librt.so.1 (0x00007f8f9bc2a000)
   libc.so.6 => /lib64/libc.so.6 (0x00007f8f9b891000)
   libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8f9b675000)
   /lib64/ld-linux-x86-64.so.2 (0x00007f8f9c070000)

So if /lib64 is not present when booting, all your booting programs are broken. While if your native 64bits booting programs were link against /lib they would.

I'm unsure how they will migrate, to good concept of /lib for 32bits and everything that is need to boot + /lib64 others non critical to boot 64bits libs or half-broken /lib for 32bits, and /lib64 for 64bits.

I think they are going for half-broken concept for me, else it would mean to migrate: identify what is in /lib64 that should goes in /lib but do not migrate it else all 64bits programs link with them to /lib64 will be broken (and glibc is one of them, meaning all programs are broken so) ; once you have the list of programs, rebuild them so they are linking themselves against /lib and no more /lib64, when it's good, remove the files from /lib64.
From the news item, i don't see anything like that said.

And seeing dhcpcd, you can see the bork concept there as it mark it as split /lib/+/lib64/
So they will move /lib64/dhcpcd files to /lib/dhcpcd and keep in /lib64/dhcpcd the libraries. Horrible! you will endup with dhcpcd that is split as:
/lib64/dhcpcd/dev (because it have udev.so in it) and /lib/dhcpcd/dhcpcd-hooks directory and /lib/dhcpcd/dhcpcd-run-hooks

If you follow LFSH, you should endup with /lib/dhcpcd holding everything, and it would be both nicer and logic!
And it's so easy to guess how it should be handle: whereis dhcpd->dhcpcd: /sbin/dhcpcd so critical to boot, must be in /lib and fuck the 64bits or 32bits concept, this is where it should be.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3850
Location: Illinois, USA

PostPosted: Sat Dec 23, 2017 1:43 am    Post subject: Reply with quote

Which binary packages were broken? I run thunderbird-bin, firefox-bin and until yesterday openoffice-bin with no problems. If libraries are confused it is the ebuild that is broken.
Also had no problems with 32-bit wine apps.

Now, on top of the pie thing we will have mandatory major surgery on our systems that have no problems. Is the intent to eliminate multilib?
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15608

PostPosted: Sat Dec 23, 2017 3:07 am    Post subject: Reply with quote

If I were to guess, I would say that krinn is speaking of proprietary binaries built to run on x86 systems, which krinn believes would run unchanged on a multilib amd64 if not for the current lib layout. I do not know if he is correct in this belief. The prebuilt binary packages for thunderbird/firefox/openoffice were built on a Gentoo system much like yours, so should be compatible with it. Running 32-bit Windows programs under 32-bit Wine is very special since Wine handles fixing up all the differences between Linux libraries and Windows libraries.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4708
Location: Dallas area

PostPosted: Sat Dec 23, 2017 10:18 am    Post subject: Reply with quote

Tony0945 wrote:

Now, on top of the pie thing we will have mandatory major surgery on our systems that have no problems. Is the intent to eliminate multilib?


The intent is seemingly to destroy gentoo as a viable distro. And they're doing a bang up job of it.
I'm glad that I've temporarily locked my profile to 13.

I'm not too happy thinking about spending time building my own system, but having to make it look like RH because the devs have fetish control freak desires to make gentoo look and act like RH.
_________________
PRIME x570-pro, 3700x, RX 550 & 560 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
bunder
Bodhisattva
Bodhisattva


Joined: 10 Apr 2004
Posts: 5907

PostPosted: Sat Dec 23, 2017 11:31 am    Post subject: Reply with quote

I don't get what the big fuss is about... granted that my 13 :arrow: 17 transitions weren't as smooth as the news article, but they weren't horrendous.

I converted 4 of my machines in the span of a week (which could have easily been done over a weekend if I did them all simultaneously)...
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3850
Location: Illinois, USA

PostPosted: Sat Dec 23, 2017 2:20 pm    Post subject: Reply with quote

Ah! I see. It's more systemd crap forced down our throats. https://bugs.gentoo.org/506276
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6628

PostPosted: Sat Dec 23, 2017 3:29 pm    Post subject: Reply with quote

*sigh* Of course it's systemd… the usual system-bricking suspects are present in that bug too.

“Proprietary x86 binaries will work better”? Nah, Steam works fine and that's pretty much the textbook definition of badly engineered proprietary code.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1501

PostPosted: Sat Dec 23, 2017 3:54 pm    Post subject: Reply with quote

Tony0945 wrote:
Ah! I see. It's more systemd crap forced down our throats. https://bugs.gentoo.org/506276
Wow...this shit has got to fucking cease. I've always been in the "Gentoo is about choice" camp, but it's pretty clear that systemd and the rest of the RH pollution is designed to snuff out all other choices. The fact that Gentoo is non-systemd by default doesn't mean shit if the majority of us have to endlessly jump through hoops because of cures for which there's no known disease just to accommodate their billshit. After having just rebuilt my companies VM appliance using Devuan 1.0...a distro that excised systemd like the fucking cancer it is...I'm starting to realize that's the only way to go.

For me, given that I went all -pie, the 13.0->17.0 move had essentially no affect on me at all. Also, given that I'm still on x86, I'm not sure any of what's going on there will either(?). But wow...Linux needs to be taken back from RH...that's pretty clear.

Tom
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15608

PostPosted: Sat Dec 23, 2017 6:09 pm    Post subject: Reply with quote

With the caveat that I stopped reading that bug about halfway down, after the discussion turned to the nuances of how and when to rearrange the directories, this doesn't seem to be particularly systemd-focused. Yes, the original reporter of the bug made the mistake of trying to debug systemd. Yes, it's at least plausible (though not clear to me that it's definitely the case) that systemd was installed incorrectly, and that if it had installed with its libdir handled correctly, the issue might not have happened. Based on comment #0, I think the root cause is that systemd installed to /usr/lib instead of /usr/$(get_libdir). The symlink made this work for regular usage (but not for debug symbols), when it really should have been rejected at build time.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Sat Dec 23, 2017 7:15 pm    Post subject: Reply with quote

Hu wrote:
this doesn't seem to be particularly systemd-focused.

Yes, it has nothing to do with systemd. It only has to do about where tools like gdb are looking for their symbols.
Quote:
systemd was installed incorrectly

No, it was installed correctly. To make tools like gdb work you would have to install the debugging systems inconsistently.
I think the better fix would be to fix gdb and friends, but AFAIK the problem is that there are some proprietary tools which cannot be fixed.

The other problem is that 32 bit binaries look hardcoded for /lib/ld-2.25.so (and not /lib32/ld-2.25.so): That's why this file exists twice on gentoo (and on debian it is a symlink).

Except for this file, separate /lib32 would be fine. I do not really see why they want to merge it to /lib: To me this seems rather broken. The debian way (binaries split in lib64 and lib32 and non-binaries in lib, with the above mentioned symlink being the only exception) appears more consistent to me.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15608

PostPosted: Sat Dec 23, 2017 7:47 pm    Post subject: Reply with quote

You say systemd was installed correctly, but it looks from that output like it was installed to /usr/lib. Am I misunderstanding the output, and it was properly installed to /usr/lib64, or are you asserting that it is proper for systemd to install a 64-bit ELF in /usr/lib?
Back to top
View user's profile Send private message
gerard27
Advocate
Advocate


Joined: 04 Jan 2004
Posts: 2377
Location: Netherlands

PostPosted: Sat Dec 23, 2017 8:39 pm    Post subject: Reply with quote

I am not sure I have sufficient understanding how it would affect my system.
I made the switch to 17.0 a while ago,I do not run systemd or debug.
Should I make the switch to 17.1?
Or can I leave things as is?

Please enlighten me.
Thanks in advance,
Gerard.
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Sat Dec 23, 2017 9:30 pm    Post subject: Reply with quote

Hu wrote:
You say systemd was installed correctly, but it looks from that output like it was installed to /usr/lib

There are libraries meant for dynamic or static linking which are (and should be) installed into /usr/lib64, and there are other architecture-dependent or -independent libs which should go into /usr/lib/subdir.
The problem is that debugging of this other data won't work since with the symlink gdb cannot understand where to look for its symbols.
In case of gdb, a solution could be to let /usr/lib/debug/ reflect the structure of the main tree, i.e. to set the symlink mentioned in the bug.
If I understand correctly, such a simple solution won't be available for other tools (valgrind?).
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Sat Dec 23, 2017 9:40 pm    Post subject: Reply with quote

gerard27 wrote:
Should I make the switch to 17.1?
Or can I leave things as is?

On the developer mailing list, it was announced that the long-term plan is that eventually all users are supposed to switch and that non-symlink (i.e. 17.1) will eventually be the only officially supported setup.

I would suggest not to hurry with this: There might occur unexpected problems with the transition leading to changes with the plan. In the best case, choice will be left to the users, although considering how gentoo evolved recently, I am not optimistic about that.
Back to top
View user's profile Send private message
gerard27
Advocate
Advocate


Joined: 04 Jan 2004
Posts: 2377
Location: Netherlands

PostPosted: Sat Dec 23, 2017 9:55 pm    Post subject: Reply with quote

Thanks mv.
I'll just wait and see.
Gerard.
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 7711
Location: Saint Amant, Acadiana

PostPosted: Sun Dec 24, 2017 3:14 am    Post subject: Reply with quote

Quote:
On the developer mailing list, it was announced that the long-term plan is that eventually all users are supposed to switch and that non-symlink (i.e. 17.1) will eventually be the only officially supported setup.

I wonder if they may change their minds. I have plenty of free time and I'd convert all my computers, but what's the use if they decide to go in a different direction. Where can I read this mailing list?
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Sun Dec 24, 2017 7:11 am    Post subject: Reply with quote

Jaglover wrote:
Where can I read this mailing list?

https://archives.gentoo.org/gentoo-dev/message/3c6680ead81abc60f6d468cd213469e8
Back to top
View user's profile Send private message
charles17
Advocate
Advocate


Joined: 02 Mar 2008
Posts: 3431

PostPosted: Sun Dec 24, 2017 9:56 am    Post subject: Reply with quote

mv wrote:
I would suggest not to hurry with this: There might occur unexpected problems with the transition leading to changes with the plan. In the best case, choice will be left to the users, although considering how gentoo evolved recently, I am not optimistic about that.

Regarding the steps listed in the mail, are all of them be needed even for a fresh install from latest stage3 tarball? Or has anyone seen (experimental) tarballs ready for 17.1?
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4708
Location: Dallas area

PostPosted: Sun Dec 24, 2017 9:59 am    Post subject: Reply with quote

~le sigh~
_________________
PRIME x570-pro, 3700x, RX 550 & 560 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Sun Dec 24, 2017 1:23 pm    Post subject: Reply with quote

charles17 wrote:
Or has anyone seen (experimental) tarballs ready for 17.1?

I doubt that there will be any very soon. Tarballs are for serious installing, not for experimenting.

Anyway, the number of steps is somewhat misleading: Essentially, each step is just a single command, and the only time-consuming steps are the rebuilding of gcc and glibc (the latter being the only package with files in /lib32 on a fresh system).
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7854
Location: Austria

PostPosted: Sun Dec 24, 2017 1:40 pm    Post subject: Reply with quote

mv wrote:
In the best case, choice will be left to the users

Choice, in this case, for what reason exactly? Once the pitfalls were figured out (and there are several, currently, I can also imagine some individual package bugs due to hardcoded libdir paths that have been working by chance so far) and the switch was proven to work fine, everyone should do it.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Sun Dec 24, 2017 3:50 pm    Post subject: Reply with quote

asturm wrote:
mv wrote:
In the best case, choice will be left to the users

Choice, in this case, for what reason exactly?

Who knows what properietary software some users are running and what is their need?
Quote:
Once the pitfalls were figured out

Nobody has all software to figure it out. It is a strategic decision which should be left to the users.

Another point is: I am not convinced that the planned layout is really good. IMHO, really natural (logically and consistent) would be the separation
  1. /lib32 for all 32 bit stuff
  2. /lib64 for all 64 bit stuff
  3. /lib for all architecture independent stuff
and not a merging of 1 and 3. AFAIK, this is what Debian is using. I am aware that this requires one inconsistent file /lib/ld-*.so (either as a copy or as a symlink to /lib32), but as long as this is the only exception, I would prefer such a clear separation.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3850
Location: Illinois, USA

PostPosted: Sun Dec 24, 2017 3:53 pm    Post subject: Reply with quote

asturm wrote:
Choice, in this case, for what reason exactly? Once the pitfalls were figured out (and there are several, currently, I can also imagine some individual package bugs due to hardcoded libdir paths that have been working by chance so far) and the switch was proven to work fine, everyone should do it.

Change for what reason exactly? I should change the layout that has served me well on half a dozen machines for over a decade just to accommodate someone who wants to install closed source 32 bit binaries on a source based distribution? Because "I'm a developer and you are a peon, so do it my way"?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum