Discussion:
[arch-general] libx264 changes
Carsten Mattner via arch-general
2017-05-07 14:51:08 UTC
Permalink
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.
Lin DasSarma
2017-05-07 14:57:07 UTC
Permalink
Carsten,

What about a custom ffmpeg PKGBUILD instead?

Lin

On 7 May 2017 at 10:51, Carsten Mattner via arch-general <
Post by Carsten Mattner via arch-general
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 Mattner via arch-general
2017-05-07 16:38:21 UTC
Permalink
Post by Lin DasSarma
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.
Doug Newgard
2017-05-07 15:01:37 UTC
Permalink
On Sun, 7 May 2017 14:51:08 +0000
Post by Carsten Mattner via arch-general
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.
Carsten Mattner via arch-general
2017-05-07 16:36:43 UTC
Permalink
Post by Doug Newgard
On Sun, 7 May 2017 14:51:08 +0000
Post by Carsten Mattner via arch-general
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.
Doug Newgard
2017-05-07 16:45:27 UTC
Permalink
On Sun, 7 May 2017 16:36:43 +0000
Post by Carsten Mattner via arch-general
Post by Doug Newgard
On Sun, 7 May 2017 14:51:08 +0000
Post by Carsten Mattner via arch-general
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.
Carsten Mattner via arch-general
2017-05-07 18:05:16 UTC
Permalink
Post by Doug Newgard
On Sun, 7 May 2017 16:36:43 +0000
Post by Carsten Mattner via arch-general
Post by Doug Newgard
On Sun, 7 May 2017 14:51:08 +0000
Post by Carsten Mattner via arch-general
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.
Doug Newgard
2017-05-07 18:11:55 UTC
Permalink
On Sun, 7 May 2017 18:05:16 +0000
Post by Carsten Mattner via arch-general
Post by Doug Newgard
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.
Carsten Mattner via arch-general
2017-05-07 18:28:08 UTC
Permalink
Post by Doug Newgard
On Sun, 7 May 2017 18:05:16 +0000
Post by Carsten Mattner via arch-general
Post by Doug Newgard
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.
Eli Schwartz via arch-general
2017-05-07 18:37:16 UTC
Permalink
Post by Carsten Mattner via arch-general
Post by Doug Newgard
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
Carsten Mattner via arch-general
2017-05-08 17:45:09 UTC
Permalink
On Sun, May 7, 2017 at 6:37 PM, Eli Schwartz via arch-general
Post by Eli Schwartz via arch-general
Post by Carsten Mattner via arch-general
Post by Doug Newgard
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.
Leonid Isaev
2017-05-08 19:15:31 UTC
Permalink
Post by Carsten Mattner via arch-general
On Sun, May 7, 2017 at 6:37 PM, Eli Schwartz via arch-general
Post by Eli Schwartz via arch-general
Post by Carsten Mattner via arch-general
Post by Doug Newgard
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
Doug Newgard
2017-05-08 19:27:04 UTC
Permalink
On Mon, 8 May 2017 13:15:31 -0600
Post by Leonid Isaev
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.
Eli Schwartz via arch-general
2017-05-08 21:15:48 UTC
Permalink
Post by Carsten Mattner via arch-general
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
Carsten Mattner via arch-general
2017-05-08 21:42:28 UTC
Permalink
On Mon, May 8, 2017 at 9:15 PM, Eli Schwartz via arch-general
Post by Eli Schwartz via arch-general
Post by Carsten Mattner via arch-general
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.
Post by Eli Schwartz via arch-general
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.
Post by Eli Schwartz via arch-general
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.
Giancarlo Razzolini
2017-05-08 21:49:20 UTC
Permalink
Post by Eli Schwartz via arch-general
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

Loading...