View previous topic :: View next topic |
Author |
Message |
Hu Administrator
Joined: 06 Mar 2007 Posts: 22626
|
Posted: Tue Sep 15, 2020 7:04 pm Post subject: |
|
|
ff11 wrote: | Hu wrote: | Note that both Flatpak and AppImage achieve their "ease" by failing to integrate with the system, and instead bundling everything the wrapped application will need. This means redundant, and potentially outdated / unmaintained / insecure, copies of libraries will be present and used by the wrapped application. | Flatpak has its own update mechanism, so it's not a bigger problem than an Linux distribution installation. | It may have an updater, but it only receives updates when the maintainers of the flattened application push them. In a Linux distribution, when upstream releases a new library version, the distribution updates its shipped version of the library, and then that library is updated for the entire system. In Flatpak, when upstream releases a new library version, every Flatpak application that bundles the library needs to release a new version with updated bundled libraries. Thus, it is a bigger problem. Or are you saying that Flathub et al. will go into all the flattened applications and update the bundled libraries in each of them, then push new versions, without requiring any action from the original developer? |
|
Back to top |
|
|
ff11 l33t
Joined: 10 Mar 2014 Posts: 664
|
Posted: Tue Sep 15, 2020 7:16 pm Post subject: |
|
|
Hu wrote: | ff11 wrote: | Hu wrote: | Note that both Flatpak and AppImage achieve their "ease" by failing to integrate with the system, and instead bundling everything the wrapped application will need. This means redundant, and potentially outdated / unmaintained / insecure, copies of libraries will be present and used by the wrapped application. | Flatpak has its own update mechanism, so it's not a bigger problem than an Linux distribution installation. | It may have an updater, but it only receives updates when the maintainers of the flattened application push them. In a Linux distribution, when upstream releases a new library version, the distribution updates its shipped version of the library, and then that library is updated for the entire system. In Flatpak, when upstream releases a new library version, every Flatpak application that bundles the library needs to release a new version with updated bundled libraries. Thus, it is a bigger problem. Or are you saying that Flathub et al. will go into all the flattened applications and update the bundled libraries in each of them, then push new versions, without requiring any action from the original developer? |
You don't need to be heated, my friend.
I'm just saying that no Linux distribution can cover every case. That there are alternatives being offered to meet this demand (that the application works the way the developer designed it to work, and doesn't change to adapt to the peculiarities of each linux distribution). And that no solution proves to be much superior to another, all have advantages and disadvantages.
So we must not be extremists who are able to accept just one type of solution. _________________ | Proverbs 26:12 |
| There is more hope for a fool than for a wise man that are wise in his own eyes. |
* AlphaGo - The Movie - Full Documentary "I want to apologize for being so powerless" - Lee |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3519
|
Posted: Tue Sep 15, 2020 7:45 pm Post subject: |
|
|
Slightly related, since I'm wanting to purge my overlays on the server if I can...
Is there a query which will tell where the installed ebuilds came from? I know if I do "emerge -p <package>" it will tell me, but if I do "emerge -ep world" it won't. I supposed I could do the second, then loop through the results doing the first. But there must be a simpler way. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
ff11 l33t
Joined: 10 Mar 2014 Posts: 664
|
Posted: Tue Sep 15, 2020 7:52 pm Post subject: |
|
|
depontius wrote: | Slightly related, since I'm wanting to purge my overlays on the server if I can...
Is there a query which will tell where the installed ebuilds came from? I know if I do "emerge -p <package>" it will tell me, but if I do "emerge -ep world" it won't. I supposed I could do the second, then loop through the results doing the first. But there must be a simpler way. |
There is probably a more elegant solution, but I use this:
Code: | To get the installed overlay names:
$ emerge --info
Then:
$ eix -I --in-overlay overlay_name
to get the installed ebuilds from the overlay
|
_________________ | Proverbs 26:12 |
| There is more hope for a fool than for a wise man that are wise in his own eyes. |
* AlphaGo - The Movie - Full Documentary "I want to apologize for being so powerless" - Lee |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6145 Location: Dallas area
|
Posted: Tue Sep 15, 2020 8:11 pm Post subject: |
|
|
depontius wrote: | Slightly related, since I'm wanting to purge my overlays on the server if I can...
Is there a query which will tell where the installed ebuilds came from? I know if I do "emerge -p <package>" it will tell me, but if I do "emerge -ep world" it won't. I supposed I could do the second, then loop through the results doing the first. But there must be a simpler way. |
equery l -F '$cpv $repo' "*"
looks like
Code: | www-client/lynx-2.8.9_p1 gentoo
www-client/palemoon-28.9.3 local |
_________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3519
|
Posted: Tue Sep 15, 2020 9:22 pm Post subject: |
|
|
Anon-E-moose wrote: | depontius wrote: | Slightly related, since I'm wanting to purge my overlays on the server if I can...
Is there a query which will tell where the installed ebuilds came from? I know if I do "emerge -p <package>" it will tell me, but if I do "emerge -ep world" it won't. I supposed I could do the second, then loop through the results doing the first. But there must be a simpler way. |
equery l -F '$cpv $repo' "*"
looks like
Code: | www-client/lynx-2.8.9_p1 gentoo
www-client/palemoon-28.9.3 local |
|
Thanks. Looks as if I'm getting two packages from overlays, neither of which I really need. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
ScardracS n00b
Joined: 03 Mar 2021 Posts: 14
|
Posted: Wed Mar 03, 2021 10:46 am Post subject: |
|
|
ff11 wrote: | NeddySeagoon wrote: | Ionen,
Its not possible to switch from no-multilib to multilib as the no-multilib toolchain in the stage3 is built with (-no-multilib).
That means all the code to build 32 bit binaries is missing, so its not possible to build gcc, glibc and friends with 32 bit support.
The switch the other way has been done, I'm sure I saw it on the forums a long time ago.
For completeness, nothing is impossible on Gentoo.
The switch from no-multilib to multilib requires an atomic replacement of the toolchain. I think that's been done too. |
Hi friends!
Around one month ago I migrated from no-multilib to multilib while developing a 64bit multilib AppImage, and I intend to go back to no-multilib after finishing this work.
Nowadays things are much easier, if no-multilib stage3 doesn't have 32bits, then just use multilib stage3 (it's not a problem).
The change to no-multilib is smooth, and doesn't need advanced procedures, just remove the ABI 32, change the profile and rebuild anything that ask to be rebuild.
To change from no-multilib to multilib, you have several options, which I will highlight 3:
* NOTE: the packages that need attention are just glibc and gcc.
1- The easiest is to use binary packages to install gcc and glibc after change the profile, but watch out for the version of glibc (don't install an older one).
2- Use the same update strategy as a very old installation to rebuild glibc and gcc after change the profile, using stage3 multilib (the method I used, because the glibc of the binary repository was with the old version):
https://wiki.gentoo.org/wiki/Upgrading_Gentoo#Updating_old_systems
3- Using only a few includes files from stage3 multilib to rebuild glibc and gcc after change the profile, as described by NTU:
https://forums.gentoo.org/viewtopic-t-1026944-start-0.html
In all these 3 options, the procedures are very simple and few for a Gentoo Linux user. So, I believe there is no need to worry about the switch. And we can be happy with the easily flexibility with which Gentoo Linux offers us |
What about move to profile no-multilib and rebuild packages that needs to be rebuilded? And if someone needs no-multilib+desktop can merge both profiles (for ex I use plasma/systemd+no-multilib) |
|
Back to top |
|
|
ff11 l33t
Joined: 10 Mar 2014 Posts: 664
|
Posted: Wed Mar 03, 2021 2:17 pm Post subject: |
|
|
ScardracS wrote: | What about move to profile no-multilib and rebuild packages that needs to be rebuilded? |
To change profile from multilib to no-multilib, just do one:
Code: | # eselect profile list
choose a profile, and set it like:
*** Beware of switching between versions of the profile (such as profile 17.0 to 17.1),
as they have specific instructions. Like:
https://www.gentoo.org/support/news-items/2019-06-05-amd64-17-1-profiles-are-now-stable.html
# eselect profile set default/linux/amd64/17.1/no-multilib
or using the number (see previous command output)
# eselect profile set 12
then rebuild (and remove packages multilib only):
# emerge -DUuavt --with-bdeps=y @world
|
ScardracS wrote: | And if someone needs no-multilib+desktop can merge both profiles (for ex I use plasma/systemd+no-multilib) |
You can make any combination you want, see:
Code: |
https://wiki.gentoo.org/wiki/Profile_(Portage) |
_________________ | Proverbs 26:12 |
| There is more hope for a fool than for a wise man that are wise in his own eyes. |
* AlphaGo - The Movie - Full Documentary "I want to apologize for being so powerless" - Lee |
|
Back to top |
|
|
ff11 l33t
Joined: 10 Mar 2014 Posts: 664
|
Posted: Thu Mar 04, 2021 11:14 am Post subject: |
|
|
ScardracS wrote: | ...we have a 64 bit machine so why run old and dirty 32 bit bits? |
I searched for answers to this question several times, and the results I got the most were "because of WINE" and "because of pcsx2" (this one now has a 64-bit version too). And I believe this is a very weak reason to keep a 32-bit system up to date on Gentoo Linux (and that's why I'm using AppImage for WINE solution). _________________ | Proverbs 26:12 |
| There is more hope for a fool than for a wise man that are wise in his own eyes. |
* AlphaGo - The Movie - Full Documentary "I want to apologize for being so powerless" - Lee |
|
Back to top |
|
|
|
|
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
|
|