Fri, 28 Jan 2022 12:28:57 +0100 Bjørn Lie <[email protected]>: > 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. Olaf
pgpr3eSQSmhOv.pgp
Description: Digitale Signatur von OpenPGP
_______________________________________________ Packman mailing list [email protected] https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
