[packman] Problems with gstreamer-plugins-bad and related packages from Packman on TW

Olaf Hering olaf at aepfle.de
Fri Jan 28 17:12:17 CET 2022

Fri, 28 Jan 2022 12:28:57 +0100 Bjørn Lie <bjorn.lie at gmail.com>:

> As to adding the "naugthy" bits in a separate spec - There is no way I 
> can get those specs into Factory, as they will not be able to build on 
> the main obs at all, since the dependencies are not available.
> If you mean doing it as a a _multibuild or old style linked spec, 
> factory maintainers will nack a non built/resolvable spec.

What I meant is a layout like this:
The gstreamer-plugins-bad pkg container continues to have a gstreamer-plugins-bad.spec, but it will get another spec file, like gstreamer-plugins-bad-nonfree.spec, the exact name does not matter.

The OBS scheduler will continue to use gstreamer-plugins-bad.spec because this spec file is named like the pkg container. The new spec file will be ignored.

In case the pkg container has some other name, and contains a _link to another gstreamer-plugins-bad pkg container, then multiple spec files exist and OBS will refuse to build. This has to be addressed with <link/patches/delete name="filename.spec"> in the _link file. As a result just a single spec file will remain and OBS will start to build this pkg container.

In case the new spec file needs to go into its own pkg container, package just a %license to get a non-empty rpm.

Independent from where the spec file is stored: Every controversial module will be build based on %bcond conditionals just like it is done today. Everything else will be disabled. It is up to you to wrap everything into a big "BUILD_ORIG" or into individual existing conditionals like "aac", "faac", "x265". They are listed in prjconf.

In pmbs a pkg container will _link to the OBS sources and build binaries with these controversial modules. OBS will build just gstreamer-plugins-bad, users have to switch vendor back to OBS once. They may not get these controversial modules by default.

But, gstreamer-plugins-bad.spec could require the "empty" gstreamer-plugins-bad-nonfree package. Then a zypper dup should be able to install the non-empty gstreamer-plugins-bad-nonfree package.

I think it may make maintenance of gstreamer easier if all package sources come from OBS, due to the version constraints in the spec files.

I think the "zypper dup" with vendor change to packman will remain until each and every package from OBS uses some sort of dlopen to load controversial binaries.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.links2linux.de/pipermail/packman/attachments/20220128/05c87572/attachment.sig>

More information about the Packman mailing list