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

[Bjørn Lie]

fr., jan. 28 2022 at kl. 17.12 +0100 +0100 skrev Olaf Hering 
<olaf at aepfle.de> følgende:
> 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.

Ok so as I said, you want to do an old style linked package, witch we 
now do via _multibuild (see 
https://build.opensuse.org/package/show/openSUSE:Factory/webkit2gtk3 as 
an example).
My initial rejection stands, Factory maintainers will most likely nack 
this approch.
I'm not saying it's impossible, but it will make maintenace of 
gstreamer-bad even harder than it is today.
For ugly, yeah sure, that one is more simple since it is way smaller 
with regards to dependencies and changes far less often.
+
we make it harder for those people who are used to rebuilding the 
bad/ugly source rpms themselves.

I'm not going to hard nack this approch, but this feels like an 
over-engineered solution (like we already have today), looking for a 
problem, instead of just doing it the simple way. 2 small, clean and 
understandable specs on packman with no conditionals at all.

Just look at 
https://pmbs.links2linux.org/package/view_file/home:zaitor/gstreamer-plugins-ugly-codecs/gstreamer-plugins-ugly-codecs.spec?expand=1

It does not get much simpler than that, and basicly any new packager 
should be able to grok what is going on here.

> 
> 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 maintain them on the obs today - trust me - it will not be.
Having a bad/ugly on obs where we do not have to "care" what happens on 
3'rd party places will be far easier.
What we have today is painfull enough, if I could with good consience 
nuke out all the "controversial" bits I'd do it in a heartbeat.
That is the beauty of having the bad/ugly-naughty bits only, what the 
main packages does not matter that much.

For version constraints, know that the stable releases are always 
backwards compatible.
Hence you could have gstreamer main package be version 1.18.5 and 
gstreamer-ugly-naughty-bits version 1.18.0.
(i've even seen working setups where the naughty bits were 2 major 
versions behind).

> 
> 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.
> 

Sure as long as we rebuild entire packages (for ffmpeg, yes, it has to 
be done there unfortunatly), but for gstreamer this is not case.


> Olaf