Bug 134727 – [GTK] Gstreamer missing from the install-dependencies script

• Status: RESOLVED
• Resolution: INVALID
• Component: Tools / Tests

[ziran sun]

Issue was found during a build in Ubuntu 14.04 from scratch.

[ziran sun]

Created attachment 234568 [details]
Patch proposal

Please review this patch

[Mario Sanchez Prada]

Comment on attachment 234568 [details]
Patch proposal

Looks good to me. Thanks!

[WebKit Commit Bot]

Comment on attachment 234568 [details]
Patch proposal

Clearing flags on attachment: 234568

Committed r170889: <http://trac.webkit.org/changeset/170889>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Philippe Normand]

What?

GStreamer is built inside the internal JHBuild. The install-dependencies script is not meant to replace the internal JHBuild setup. Please revert this change.

[Martin Robinson]

(In reply to comment #5)
> GStreamer is built inside the internal JHBuild. The install-dependencies script is not meant to replace the internal JHBuild setup. Please revert this change.

I have to agree here.

[Philippe Normand]

The function to install RPM deps is also quite over-crowded, what happened with that?

The install-dependencies script was abused, it should really install only the strict necessary dependencies to bootstrap and build JHBuild :( Unless I misunderstood its purpose?

[WebKit Commit Bot]

Re-opened since this is blocked by bug 134754

[Philippe Normand]

(In reply to comment #7)
> The function to install RPM deps is also quite over-crowded, what happened with that?
> 
> The install-dependencies script was abused, it should really install only the strict necessary dependencies to bootstrap and build JHBuild :( Unless I misunderstood its purpose?

Filed Bug 134755 about this.

[Mario Sanchez Prada]

(In reply to comment #6)
> (In reply to comment #5)
> > GStreamer is built inside the internal JHBuild. The install-dependencies script is not meant to replace the internal JHBuild setup. Please revert this change.
> 
> I have to agree here.

I disagree, though. JHBuild is a helper tool that enable people to build WebKit when system packages are not recent enough, as well as to help "normalize" testing environments such as the ones used in the bots.

However, I don't see what's the point of having to build all the deps if your distro have recent enough versions of those packages (e.g. Ubuntu 14.04 at this time), but in order to do that the developer would need to install these 2 gstreamer devel packages first, as they are core deps of WebKit.

On top of that, I don't see any collision between having these 2 packages in the apt-get section of the install-dependencies script (as it's done already for the yum section, btw) and building gstreamer anyway in the jhbuild moduleset:

 - If you execute both install-dependencies and update-webkitgtklibs, WebKit will pick the versions from the jhbuild, as they likely are newer. No conflict here.

 - If you don't execute update-webkitgtklibs, then WebKit will use the (recent enough) versions in your system, saving you time.

In both cases it's a Win-Win situation, while keeping these 2 packages out of the install-dependencies script means only the first scenario will work.

Last, I was pointed to http://trac.webkit.org/wiki/BuildingGtk as proof that both steps should be executed, but I think that's a mistake too, as you can certainly build and run WebKitGTK if the system is new enough without using the jhbuild at all.

So, could you please ellaborate a bit more in how exactly including those _core_ deps in install-dependencies is a bad thing? So far I can't see any good reason, to be honest

[Martin Robinson]

(In reply to comment #10)

> However, I don't see what's the point of having to build all the deps if your distro have recent enough versions of those packages (e.g. Ubuntu 14.04 at this time), but in order to do that the developer would need to install these 2 gstreamer devel packages first, as they are core deps of WebKit.

install-dependencies and the JHBuild are complementary tools, so it would be best, in my opinion, to avoid overlap. Isn't there a mode where JHBuild can install dependencies from the system?

[Martin Robinson]

(In reply to comment #11)

> install-dependencies and the JHBuild are complementary tools, so it would be best, in my opinion, to avoid overlap. Isn't there a mode where JHBuild can install dependencies from the system?

Yes, perhaps people who *really* don't want to use the JHBuild can simply use jhbuild sysdeps. I think it would be alright with me if install-dependencies had another mode install-dependencies --avoid-jhbuild, or whatever, that called jhbuild sysdeps.

[Carlos Alberto Lopez Perez]

For the record, my understanding is the following:

The purpose of the internal JHBuild is to build _specific_ versions (note the specific: it don't matters if is newer or older, but the exact version) of the dependencies that could make the layout tests behave different (ex: the typical one pixel difference).

So the only way of running the layout tests and getting consistent results is using the internal JHBuild.

When we raise the version of a library of the JHBuild, we also have to rebaseline a bunch of tests that will give different results with the new version of that library.

While is true that you can use your system libraries on a modern enough distribution, you can't be sure that the results you are getting for the layout tests are consistent with what the rest of developers (and the bots) get.

The purpose of the script update-webkitgtklibs is to install the system dependencies required to bootstrap the internal JHBuild, as also to install the system dependencies required to build webkitgtk+ that are not provided in the JHBuild (because that dependencies won't affect the results of the layout tests).

[Martin Robinson]

(In reply to comment #13)
> For the record, my understanding is the following:

Yeah, your understanding is spot on, I'd say. Some people do need to build trunk and don't care about layout tests. I think adding an option to do that isn't a bad idea, but hopefully we can do it without duplicating the package lists.