| View previous topic :: View next topic |
| Author |
Message |
nicholfd
n00b
Joined: 25 Mar 2008
Posts: 11
|
 Posted: Mon May 28, 2018 2:00 am Post subject: Why does VLC 3.x require virtual/opengl? |
 |
|
I use VLC on Raspberry Pi's to stream the Raspberry Pi camera. All of the Pis are headless and boot without a GUI - no X or windowing environment. Versions of VLC 2.x emerged just find and had no dependance on virtual/opengl.
Why does VLC 3.x have a hard dependency on virtual/opengl? This causes several large packages to be brought in, including part of X, LLVM, mesa, etc. Some of these will not build on the Raspberry Pi.
Note that I checked the ebuild files. All versions of VLC 3.x have virtual/opengl in the "RDEPEND" section. The VLC 2.x ebuild files have virtual/opengl as USE flag, but not dependancy.
Thanks,
Frank |
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon May 28, 2018 4:31 am Post subject: |
|
|
Not sure exactly what it means, but there's a related comment on github. | Quote: | media-video/vlc: Drop USE=opengl, it was 100% automagic
Don't pretend we have a choice right now, re-adding the USE needs patching. |
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
nicholfd
n00b
Joined: 25 Mar 2008
Posts: 11
|
| Posted: Mon May 28, 2018 1:45 pm Post subject: |
|
|
Thanks for researching that.
The behavior on 2.x has the use flag, and builds on my systems without pulling in any X or OpenGL items. I didn't even have the "-opengl" in USE flags, and it still didn't pull in OpenGL/X. There is no GUI and it does my streaming just fine. It has this in the ebuild:
| Code: | | opengl? ( virtual/opengl:0 >=x11-libs/libX11-1.3.99.901:0 ) |
Doe that make OpenGL conditional on libX11, or mean it requires libX11?
Thanks,
Frank |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon May 28, 2018 3:42 pm Post subject: |
|
|
I believe what that indicates is if the opengl USE flag is set, require the specified versions of virtual/opengl and x11-libs/libX11.
You may (or may not) find this helpful:
https://devmanual.gentoo.org/general-concepts/dependencies/
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Mon May 28, 2018 4:14 pm Post subject: |
|
|
| The old opengl USE flag had no effect on the build system which is a big no-no. VLC's buildsystem decides to build with OpenGL purely depending on availability, no matter if you disabled the flag. This needs patching and upstreaming. |
|
| Back to top |
|
|
nicholfd
n00b
Joined: 25 Mar 2008
Posts: 11
|
| Posted: Mon May 28, 2018 4:59 pm Post subject: |
|
|
| asturm wrote: | | The old opengl USE flag had no effect on the build system which is a big no-no. VLC's buildsystem decides to build with OpenGL purely depending on availability, no matter if you disabled the flag. This needs patching and upstreaming. |
Thanks for the update.
I have "-X" in my USE flags. There is no hint of X/X11 on my system. The VLC 3.x build ALWAYS forces OpenGL (mesa in my case). This brings in LLVM and other packages that have difficulty building on a Raspberry Pi (memory limit).
I'm not necessarily a developer (just some Python/Perl/BASH). Is there something I should do to get them to review this? Would that help bring Gentoo back to the VLC 2.x build behavior (of not requiring OpenGL)? Or is this something completely about how the VideoLAN folks changed their build system for the VLC 3.x release?
Thanks,
Frank |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Mon May 28, 2018 5:12 pm Post subject: |
|
|
| No, 2.x was broken already. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon May 28, 2018 5:40 pm Post subject: |
|
|
| asturm wrote: | | VLC's buildsystem decides to build with OpenGL purely depending on availability, no matter if you disabled the flag. This needs patching and upstreaming. |
Sure, but why force it on? You could just as easily leave it out, and leave the admins' choice of X or not, to influence the build in line with upstream, which would be a much better intermediate step until it is patched. (or indeed only force the dependency when the flag is on, wrt keeping the system maintained.)
I'm guessing there are some bugs on this, but not mentioned in the commit, and you sound like you know the issue; any link to the offending build files you want patched? |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Mon May 28, 2018 6:53 pm Post subject: |
|
|
I happen to have made 90% of vlc commits in recent times, cleanups it had needed badly. The opengl automagic was just one of the issues that were uncovered during the process, and it is not yet clear what is needed for it to be fixed effectively. If you look at the commit, the old opengl use flag did not even pretend to refer to a build system switch. Right now the ebuild is consistent in that a given set of use flags yields a predictable binary. I would much prefer a proper solution but did not have the time yet. To be patched is VLC's complicated autotools system, but we need to find out what feature set would enable us to disable opengl without causing build errors.
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Tue May 29, 2018 12:03 am Post subject: |
|
|
| OP: since this is an automagic dependency and you have specifically indicated you want to avoid ever installing the OpenGL packages on that system for any reason, you could use a local overlay to remove the dependency. If you do, you should be aware that if you ever install those OpenGL packages, then subsequently rebuild vlc, then vlc will depend on those OpenGL packages despite your ebuild not telling it to do so. This is why automagic dependencies are considered a QA violation. They lead to surprising results. |
|
| Back to top |
|
|
nicholfd
n00b
Joined: 25 Mar 2008
Posts: 11
|
| Posted: Tue May 29, 2018 12:12 am Post subject: |
|
|
Would it help for some of us (I'm willing) to question this to the VideoLAN goup (assuming it has not been done yet)? I'm willing to ask for info/suggest improvements, if someone can point me in the right direction.
Thanks,
Frank |
|
| Back to top |
|
|
nicholfd
n00b
Joined: 25 Mar 2008
Posts: 11
|
| Posted: Tue May 29, 2018 12:16 am Post subject: |
|
|
| Hu wrote: | | OP: since this is an automagic dependency and you have specifically indicated you want to avoid ever installing the OpenGL packages on that system for any reason, you could use a local overlay to remove the dependency. If you do, you should be aware that if you ever install those OpenGL packages, then subsequently rebuild vlc, then vlc will depend on those OpenGL packages despite your ebuild not telling it to do so. This is why automagic dependencies are considered a QA violation. They lead to surprising results. |
Thanks for the suggestion.
I've been using Gentoo for 10+ years. However, I don't have much experience with overlays. I understand the general idea, but have never tried to use one. I like to KISS - especially on Raspberry Pis. If I did want to try an overly, can you point me to a good how-to or reverence?
If I did use an overlay, it's possible VLC would possibly not build or not work properly when built. Even with 12+ Pis building with DISTCC, it still takes a while to build some of these packages...
Thanks,
Frank |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8935
|
| Posted: Tue May 29, 2018 6:48 am Post subject: |
|
|
| You could also put virtual/opengl into package.provided. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed May 30, 2018 4:55 pm Post subject: |
|
|
| asturm wrote: | | I happen to have made 90% of vlc commits in recent times, cleanups it had needed badly. The opengl automagic was just one of the issues that were uncovered during the process, and it is not yet clear what is needed for it to be fixed effectively. If you look at the commit, the old opengl use flag did not even pretend to refer to a build system switch. Right now the ebuild is consistent in that a given set of use flags yields a predictable binary. I would much prefer a proper solution but did not have the time yet. |
The trouble is that you've "fixed" it by making it enforce dependencies, which is fine in the case of X/opengl on-system, but precisely the wrong thing when not.
It would be better to revert that change IMO, and leave the USE-flag enforcing dependencies (with an ewarn) until it is properly-corrected, so that you don't break end-user setups.
Remember: you're a distribution working on behalf of end-users, first and last. | Quote: | | To be patched is VLC's complicated autotools system, but we need to find out what feature set would enable us to disable opengl without causing build errors. |
You sound like you're unsure about autotools; ##workingset (for the umpteenth time.)
There is no shame in not knowing everything; the shame comes from not taking advice and thus not learning, especially when that's because of its source.
Sorry but the bit about "feature-set" is nonsense, when it clearly builds fine without opengl, since the build-system "automagically" detects its presence. |
|
| Back to top |
|
|
nicholfd
n00b
Joined: 25 Mar 2008
Posts: 11
|
| Posted: Sun Jun 03, 2018 8:09 pm Post subject: |
|
|
| steveL wrote: | The trouble is that you've "fixed" it by making it enforce dependencies, which is fine in the case of X/opengl on-system, but precisely the wrong thing when not.
It would be better to revert that change IMO, and leave the USE-flag enforcing dependencies (with an ewarn) until it is properly-corrected, so that you don't break end-user setups.
Remember: you're a distribution working on behalf of end-users, first and last. |
+1 to this! |
|
| Back to top |
|
|
|
Multimedia
