[arch-general] libx264 changes
Since the libx264 package does not include /usr/include and it's in x264 now, and because x264 depends on ffmpeg, I cannot use libx264 without also installing ffmpeg. For various reasons like missing features and wrong version I cannot use arch's ffmpeg package and have to build my own package, and this results in a cyclic dependency I cannot get out of. (lib)x264 packages have always been cumbersome due to 8bit vs 10bit and other issues and are uniquely special in arch, but since there's already so many x264 packages, let's have a libx264-headers package. Or keep it in libx264 since 8bit and 10bit cannot be installed in parallel anyway. Doug, you probably have good reasons for the recent headers change and see no way to fix it to make my scenario work, but I'd appreciate if you gave this a thought and shared your opinion. If you can't fix this, do you mind explaining what led to the removal of headers from libx264? I hope I don't have to build libx264 myself as well since my PKGBUILD would diverge or force me to build libx264 and x264 custom versions.
Carsten, What about a custom ffmpeg PKGBUILD instead? Lin On 7 May 2017 at 10:51, Carsten Mattner via arch-general < arch-general@archlinux.org> wrote:
Since the libx264 package does not include /usr/include and it's in x264 now, and because x264 depends on ffmpeg, I cannot use libx264 without also installing ffmpeg.
For various reasons like missing features and wrong version I cannot use arch's ffmpeg package and have to build my own package, and this results in a cyclic dependency I cannot get out of.
(lib)x264 packages have always been cumbersome due to 8bit vs 10bit and other issues and are uniquely special in arch, but since there's already so many x264 packages, let's have a libx264-headers package. Or keep it in libx264 since 8bit and 10bit cannot be installed in parallel anyway.
Doug, you probably have good reasons for the recent headers change and see no way to fix it to make my scenario work, but I'd appreciate if you gave this a thought and shared your opinion. If you can't fix this, do you mind explaining what led to the removal of headers from libx264?
I hope I don't have to build libx264 myself as well since my PKGBUILD would diverge or force me to build libx264 and x264 custom versions.
On Sun, May 7, 2017 at 2:57 PM, Lin DasSarma <__@umbc.edu> wrote:
Carsten,
What about a custom ffmpeg PKGBUILD instead?
That's what I've been doing which got complicated now that x264.h is not in libx264 but x264 and x264 depends on ffmpeg for presumably muxing. We have more than two x264 packages so a x264-headers could solve this.
On Sun, 7 May 2017 14:51:08 +0000 Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
For various reasons like missing features and wrong version I cannot use arch's ffmpeg package and have to build my own package, and this results in a cyclic dependency I cannot get out of.
What, exactly, is the issue here? You need an ffmpeg package that provides what x264 needs, nothing more.
On Sun, May 7, 2017 at 3:01 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Sun, 7 May 2017 14:51:08 +0000 Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
For various reasons like missing features and wrong version I cannot use arch's ffmpeg package and have to build my own package, and this results in a cyclic dependency I cannot get out of.
What, exactly, is the issue here? You need an ffmpeg package that provides what x264 needs, nothing more.
I cannot install libx264's include/x264.h without installing x264 which then depends on ffmpeg which itself depends on libx264. This doesn't look like a hard cycle since it seems like only the x264 executable needs libav*.so, but since x264.h was in libx264 (and is in extra still), I've been building a custom ffmpeg package without also having to build a custom configured (lib)x264 too.
On Sun, 7 May 2017 16:36:43 +0000 Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
On Sun, May 7, 2017 at 3:01 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Sun, 7 May 2017 14:51:08 +0000 Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
For various reasons like missing features and wrong version I cannot use arch's ffmpeg package and have to build my own package, and this results in a cyclic dependency I cannot get out of.
What, exactly, is the issue here? You need an ffmpeg package that provides what x264 needs, nothing more.
I cannot install libx264's include/x264.h without installing x264 which then depends on ffmpeg which itself depends on libx264. This doesn't look like a hard cycle since it seems like only the x264 executable needs libav*.so, but since x264.h was in libx264 (and is in extra still), I've been building a custom ffmpeg package without also having to build a custom configured (lib)x264 too.
So what? None of that should cause a problem if your custom ffmpeg package is done correctly.
On Sun, May 7, 2017 at 4:45 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Sun, 7 May 2017 16:36:43 +0000 Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
On Sun, May 7, 2017 at 3:01 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Sun, 7 May 2017 14:51:08 +0000 Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
For various reasons like missing features and wrong version I cannot use arch's ffmpeg package and have to build my own package, and this results in a cyclic dependency I cannot get out of.
What, exactly, is the issue here? You need an ffmpeg package that provides what x264 needs, nothing more.
I cannot install libx264's include/x264.h without installing x264 which then depends on ffmpeg which itself depends on libx264. This doesn't look like a hard cycle since it seems like only the x264 executable needs libav*.so, but since x264.h was in libx264 (and is in extra still), I've been building a custom ffmpeg package without also having to build a custom configured (lib)x264 too.
So what? None of that should cause a problem if your custom ffmpeg package is done correctly.
I have to override/repackage two packages now that x264.h is in a package which leads me into a cycle. Or I repackage ffmpeg, x264, libx264 locally, not just ffmpeg as before. I respect your decision, but I can't find the justification. (lib)x264 packaging has been problematic due to 8bit/10bit in the past as well and I'm certain it's not an easy package to be responsible for. In fact I remember that the header moved around in the packages once before (maybe 2 years ago). x264's new feature flag to depend on libav* is recent and is the source of the cycle.
On Sun, 7 May 2017 18:05:16 +0000 Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
On Sun, May 7, 2017 at 4:45 PM, Doug Newgard <scimmia@archlinux.info> wrote:
So what? None of that should cause a problem if your custom ffmpeg package is done correctly.
I have to override/repackage two packages now that x264.h is in a package which leads me into a cycle. Or I repackage ffmpeg, x264, libx264 locally, not just ffmpeg as before.
And again, the cycle doesn't matter at all if your ffmpeg package is set up correctly.
On Sun, May 7, 2017 at 6:11 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Sun, 7 May 2017 18:05:16 +0000 Carsten Mattner via arch-general <arch-general@archlinux.org> wrote:
On Sun, May 7, 2017 at 4:45 PM, Doug Newgard <scimmia@archlinux.info> wrote:
So what? None of that should cause a problem if your custom ffmpeg package is done correctly.
I have to override/repackage two packages now that x264.h is in a package which leads me into a cycle. Or I repackage ffmpeg, x264, libx264 locally, not just ffmpeg as before.
And again, the cycle doesn't matter at all if your ffmpeg package is set up correctly.
I don't understand how I can without additionally repacking libx264/x264, but hopefully I will see what you're saying later today or tomorrow.
On 05/07/2017 02:28 PM, Carsten Mattner via arch-general wrote:
On Sun, May 7, 2017 at 6:11 PM, Doug Newgard <scimmia@archlinux.info> wrote:
And again, the cycle doesn't matter at all if your ffmpeg package is set up correctly.
I don't understand how I can without additionally repacking libx264/x264, but hopefully I will see what you're saying later today or tomorrow.
What Doug is saying is, you should do what 99.9999999% of all other Arch Linux users creating custom packages to replace repo packages do, and make your forked ffmpeg package provide "ffmpeg", thereby ensuring that libx264/x264 depend on *your* package! -- Eli Schwartz
On Sun, May 7, 2017 at 6:37 PM, Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
On 05/07/2017 02:28 PM, Carsten Mattner via arch-general wrote:
On Sun, May 7, 2017 at 6:11 PM, Doug Newgard <scimmia@archlinux.info> wrote:
And again, the cycle doesn't matter at all if your ffmpeg package is set up correctly.
I don't understand how I can without additionally repacking libx264/x264, but hopefully I will see what you're saying later today or tomorrow.
What Doug is saying is, you should do what 99.9999999% of all other Arch Linux users creating custom packages to replace repo packages do, and make your forked ffmpeg package provide "ffmpeg", thereby ensuring that libx264/x264 depend on *your* package!
Is the idea that I create a machine local repo that has highest prio and overrides arch extra/testing? Otherwise, I don't know how to unbreak the cycle while only building a custom ffmpeg.
On Mon, May 08, 2017 at 05:45:09PM +0000, Carsten Mattner via arch-general wrote:
On Sun, May 7, 2017 at 6:37 PM, Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
On 05/07/2017 02:28 PM, Carsten Mattner via arch-general wrote:
On Sun, May 7, 2017 at 6:11 PM, Doug Newgard <scimmia@archlinux.info> wrote:
And again, the cycle doesn't matter at all if your ffmpeg package is set up correctly.
I don't understand how I can without additionally repacking libx264/x264, but hopefully I will see what you're saying later today or tomorrow.
What Doug is saying is, you should do what 99.9999999% of all other Arch Linux users creating custom packages to replace repo packages do, and make your forked ffmpeg package provide "ffmpeg", thereby ensuring that libx264/x264 depend on *your* package!
Is the idea that I create a machine local repo that has highest prio and overrides arch extra/testing? Otherwise, I don't know how to unbreak the cycle while only building a custom ffmpeg.
I don't understand... testing/libx264 contains /usr/include/x264.h and doesn't depend on ffmpeg, no? Cheers, -- Leonid Isaev
On Mon, 8 May 2017 13:15:31 -0600 Leonid Isaev <leonid.isaev@jila.colorado.edu> wrote:
I don't understand... testing/libx264 contains /usr/include/x264.h and doesn't depend on ffmpeg, no?
Cheers,
There's been another reshuffle of the x264 packages. The "lib" packages were just symlinks when this thread started.
On 05/08/2017 01:45 PM, Carsten Mattner wrote:
Is the idea that I create a machine local repo that has highest prio and overrides arch extra/testing? Otherwise, I don't know how to unbreak the cycle while only building a custom ffmpeg.
Granted that it is a moot point anyway since your initial request was answered and the package is now rebuilt with the headers in the lib package... But no, why does a local repo have anything to do with anything? Do you feel you need a local repo in order to install a pacman package, or have you discovered the magical -U switch yet? Just makepkg your custom PKGBUILD, and then install your custom ffmpeg in place of the repo version. Seriously, did you even try it at all? Because if you had tried it, it would have worked and you wouldn't be having all these strange questions. In the absolute worst-case scenario imaginable, you would have to temporarily have a few wasteful packages installed, including the repo ffmpeg, WHICH YOU WOULD THEN UNINSTALL AFTER YOU BUILT YOUR OWN FFMPEG! Why are you making such a circus out of this??? -- Eli Schwartz
On Mon, May 8, 2017 at 9:15 PM, Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
On 05/08/2017 01:45 PM, Carsten Mattner wrote:
Is the idea that I create a machine local repo that has highest prio and overrides arch extra/testing? Otherwise, I don't know how to unbreak the cycle while only building a custom ffmpeg.
Granted that it is a moot point anyway since your initial request was answered and the package is now rebuilt with the headers in the lib package...
But no, why does a local repo have anything to do with anything? Do you feel you need a local repo in order to install a pacman package, or have you discovered the magical -U switch yet?
I ask because pacman -U is the usual way I install custom packages.
Just makepkg your custom PKGBUILD, and then install your custom ffmpeg in place of the repo version. Seriously, did you even try it at all? Because if you had tried it, it would have worked and you wouldn't be having all these strange questions.
In the absolute worst-case scenario imaginable, you would have to temporarily have a few wasteful packages installed, including the repo ffmpeg, WHICH YOU WOULD THEN UNINSTALL AFTER YOU BUILT YOUR OWN FFMPEG!
I did try and the only way I managed was building ffmpeg after first building a custom x264 that doesn't depend on x264. I didn't manage to build and install ffmpeg without installing the vanilla ffmpeg package first as a dependency of x264. I'm sure I'm just not seeing the obvious and sorry for my limited perspective here. For some reason we seem to be talking past each other and these things happen in online discussions. Since the header is included in a cycle-free fashion again, we should end this thread as I'm afraid my failure to see what you've been suggesting won't be cleared via email.
Why are you making such a circus out of this???
I'm sorry you think I am, but I don't think I can say anything to convince you otherwise. Eli, sorry for asking dumb question that likely stem from different perspectives and my pacman/makepkg experience.
Em maio 8, 2017 18:15 Eli Schwartz via arch-general escreveu:
Why are you making such a circus out of this???
I ask you the same. Please stop replying to others using phrases in all caps. Thank you, Giancarlo Razzolini
participants (6)
-
Carsten Mattner
-
Doug Newgard
-
Eli Schwartz
-
Giancarlo Razzolini
-
Leonid Isaev
-
Lin DasSarma