Add missing metapackages for tdebindings in DEB #5

As per title. Installing those metapackages would pull in all tdebindings packages in one shot.

Intended for R14.1 only.

Please comment before I merge.

Does such a package have any benefits? The individual programming languages for which bindings are created are so different that it does not seem to be useful, for example, with Ruby bindings to install huge Java packages.

I understand meta packages that have a sense for the user - for example: "I want everything for graphics, because I want to first try which program will suit me best." But it does not make much sense for programming languages.

probably not useful for users, but useful for developers. If I want all bindings at once, I just install those metapackages. Each of the two additional metapackage is 11K only, so not much difference in terms of downloading.

Exactly for developers, I do not see such a meta package as useful. When someone is programming in Ruby, why would they be interested in installing bindings for Python or Java and all their dependencies? Meta packages and bindings itself will be small, but their dependence may be giant - for example, JRE. That's why my question to whom this meta package can be beneficial.

If a user wants only python (or java or ruby...) binding, they can install only the required packages.

But if you want to install all bindings, a user need to search what pakcages to install and may miss out on some. A user may not know the names of all binding packages, since most of them do not begin with tdebindings (only the java one do). For example, how is a user supposed to know that "libkjsembed1-trinity...." is providing some binding info?

A meta package provides an easy way to pull in all TDE bindings for users who don't want to spend time looking for packages names. It also provide an easy way to remove all binding packages if no longer needed.

But if you think those two metapackages aer not useful, we can't just close the PR and don't merge. IMO, I see no harm in having two more small metapackages 😃

Ok, the argument for simplifying the search for bindings for the specific programming language is good. Even a developer does not need to know the name of the integration package for a particular programming language, so the meta package can be useful for that. Now it's a good sense 👍

That was exactly the issue I had earlier and why I decided to create the meta packages 😄

Merged and pushed upstream.