| View previous topic :: View next topic |
| Author |
Message |
saellaven
l33t
Joined: 23 Jul 2006
Posts: 657
|
 Posted: Sun May 04, 2025 5:05 pm Post subject: |
 |
|
| szatox wrote: |
In the meantime, I fixed video playback in palemoon. Its ebuild has a botched dependency, which allows ffmpeg-7, but then attempts to open a bunch if older versions of libavcodec and ends up not finding the one that is actually installed. So this one really was just a coincidence. |
Mind tossing me that patch?
_________________
Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc |
|
| Back to top |
|
 |
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2982
|
| Posted: Sun May 04, 2025 5:06 pm Post subject: |
|
|
| szatox wrote: | | logrusx wrote: |
Yup. Definitely a misunderstanding here. Or lack of understanding.
I will repeat - some apps can use multiple python implementations, others can't. The ones that can't lock other apps with the same implementation they use. That's not some general rule you're citing, that's python specific.
|
We're talking about whether a certain functionality, which is not implemented, would be a good feature to have or not, and how would it work. It's the realm of what-ifs.
Are you seriously telling me that a thing that doesn't exist yet, does not work? |
Single-impl packages can only import modules from a specific implementation. That brings the implication that their reverse dependencies have no way of using a different implementation, getting locked to that same implementation and effectively becoming single-impl packages. I'm not sure how far that propagates into the dependency graph, it might very well be further than I can see.
Let's pretend somebody implemented that. Very few packages would benefit from it, but that would defeat the purpose because clusters or packages would form around those single targets which would improve nothing. Packages will "spill over" from one single target cluster to another, carrying with them big amounts of rebuilds. Furthermore multiple-impl packages would get rebuilt with every new target getting added or removed. It would only cause even bigger mess and won't in any way be more convenient. Not to mention the unreasonable amount of work that the implementation of that would require. Moreover that would require extensive amount of testing the new versions too. The binhost would be overwhelmed too.
That's not going to happen any time soon, if at all, unless something fundamental changes in python. There certainly is space for improvement and it most certainly will happen, but not in the drastic way you envision it.
Best Regards,
Georgi |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3648
|
| Posted: Sun May 04, 2025 6:56 pm Post subject: |
|
|
| saellaven wrote: |
Mind tossing me that patch? |
I just solved it manually with emerge =ffmpeg-6*, but this works too:
| Code: | diff --git a/www-client/palemoon/palemoon-33.7.0.ebuild b/www-client/palemoon/palemoon-33.7.0.ebuild
index 913bc89..b582956 100644
--- a/www-client/palemoon/palemoon-33.7.0.ebuild
+++ b/www-client/palemoon/palemoon-33.7.0.ebuild
@@ -59,7 +59,7 @@ RDEPEND="
media-libs/alsa-lib
pulseaudio? ( media-libs/libpulse )
- media-video/ffmpeg[x264]
+ <media-video/ffmpeg-7[x264]
necko-wifi? ( net-wireless/wireless-tools )
"
|
logrusx, great, now you're bringing actual concerns. I think you're overestimating the necessary "stickiness" of single target apps, and it somehow makes things more rigid than only having one, system-wide single_target. On top of that, I think it's easier to deal with a dozen of small problems than one huge, and being able to test things out one at a time and release as they're ready fits a rolling disto better than "Every May the next python take over your @world". Would it be more work overall? I don't know.
Will it ever be implemented? Probably not. Question is: because it's a bad idea, because it's too much work to switch, or because it's a different approach, and Gentoo became a distro for old-farts, and all the cool kids hang out around Arch those days? 
Oh, I almost forgot: Happy Star Wars Day, everyone!
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2326
|
| Posted: Sun May 04, 2025 8:50 pm Post subject: |
|
|
| Life is easy with no slot support. |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4757
Location: Germany
|
| Posted: Sun May 04, 2025 10:43 pm Post subject: |
|
|
@szatox
media-video/ffmpeg-compat:6[x264] Slot is probably the better way. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3648
|
| Posted: Mon May 05, 2025 9:10 am Post subject: |
|
|
No, it doesn't need to be 6. 4 worked on my system just fine until last week, haven't tested 5, but it will surely do as well. You can even enable outdated codecs at runtime, which I suppose would allow you to use 3 (not in portage anymore).
Only 7 is too new to to be tested for.
A better solution would be to open libavcodec.so rather than libavcodec.so.{60,59,58,57,56..} while completely ignoring libavcodec.so.61, but faking a symlink didn't cut it.
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
Zarhan
Veteran
Joined: 27 Feb 2004
Posts: 1020
|
| Posted: Mon May 05, 2025 11:01 am Post subject: |
|
|
| For me, I had to uninstall stellarium, aircrack, tcpreplay and android-tools. I'm not using them at this time so I didn't pin Python 3.12, but very poor handling of stable systems breakage. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2982
|
| Posted: Mon May 05, 2025 11:23 am Post subject: |
|
|
| Zarhan wrote: | | For me, I had to uninstall stellarium, aircrack, tcpreplay and android-tools. I'm not using them at this time so I didn't pin Python 3.12, but very poor handling of stable systems breakage. |
Don't forget to file bugs if there aren't. This helps too.
Best Regards,
Georgi |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 657
|
| Posted: Mon May 05, 2025 11:36 am Post subject: |
|
|
| szatox wrote: | | saellaven wrote: |
Mind tossing me that patch? |
I just solved it manually with emerge =ffmpeg-6*, but this works too:
|
Thanks. Someone posted a thread in the palemoon forums on it as well.
_________________
Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc |
|
| Back to top |
|
|
Zarhan
Veteran
Joined: 27 Feb 2004
Posts: 1020
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23434
|
| Posted: Tue May 06, 2025 5:50 pm Post subject: |
|
|
As I said above, the switch cannot be held back indefinitely. I suspect the switch date was picked with the hope that all core packages would be ready by the switch date.
For the bugs you cited, one had already been fixed, and none of the others had received even a token comment protesting about the need for more time. If the maintainer for the package neither adjusts it, nor requests more time to do so, how long would you expect the Gentoo Python team to sit by and wait? |
|
| 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
|
|
Portage & Programming
