[mythtv-users] Packaging MythTV (was Best distribution for MythTV)

[Paul Gardiner]

On 13/09/2020 13:41, John Pilkington wrote:
> On 13/09/2020 12:59, Paul Gardiner wrote:
>> On 01/09/2020 12:43, Paul Gardiner wrote:
>>> On 01/09/2020 12:34, beppo wrote:
>>>>
>>>> Hi,
>>>>
>>>> you don't need to change your distro, I build my own rpms for 
>>>> OpenSUSE for
>>>> years now.
>>>> I use the spec files from the Packman repo and modify it for 
>>>> mythtv-v31.
>>>>
>>>> If you are interested, I can share you spec file.
>>>
>>> This is excellent. I have a very clear way forward now, and two 
>>> possible sources for spec files.
>>>
>>> Thank you so much to all the helpful people that have made comments.
>>
>> And thank you again everyone who replied. Taking on bits of advice 
>> from the various replies, I am now on v31 without changing distro and 
>> without losing my use of kiwi to create front-end images.
>>
>> I decided to go for the start-my-own-packaging-from-scratch option, 
>> thinking that I may end up with a simpler spec file than the one that 
>> packman uses, although I have to admit - as I work on it - I'm finding 
>> many of the complications are necessary, and possibly almost all will 
>> return if I wish my spec file to be of general use to others. There's 
>> still the advantage that I can check into git the various stages so 
>> that I have a record of what the various bits are for.
>>
>> I didn't see a way to use the ansible playbook directly, but I cribbed 
>> almost all my BuildRequires lines from perusal of the playbook source. 
>> I seemed to need a few more for the jump from 29.1 to 31, but those I 
>> found in some info that Beppo kindly sent to me.
>>
>> I have a working system, but there are still some issues I'll need to 
>> sort out long term:
>>
>> 1. I haven't added many Requires lines. Library dependencies seem to 
>> be generated mostly automatically, but I guess I'll find others I need 
>> when I try installing on a fresh system that hasn't previously run 
>> MythTV.
>>
>> 2. I currently generate a single package. At some state, I'll want to 
>> break it up into smaller ones. (my frontend disc image is 200MB bigger 
>> because of not having done so). The problem here is working out what 
>> uses what. I don't want to just copy from another spec file, and I 
>> don't want to spend hours looking for error messages of one component 
>> reporting another missing. I'm wondering what other options there 
>> might be to discover the dependency graph.
>>
>> 3. I'm not currently building the plugins. The build for these seems 
>> to be a nightmare for packagers (if I'm understanding correctly). The 
>> plugins build requires the core of mythtv to be both built and 
>> installed. The packman spec file uses a work around I really rather 
>> not copy. I'm considering using two package generation stages with two 
>> spec files, the second using the source package from the first, but 
>> this may not work and is inefficient as it involves building the core 
>> twice. I'm wondering what other options there are... maybe changing 
>> the mythtv source would be best.
> 
> I understand why you have taken that route, and it's good to hear about 
> your progress - but another comment seems appropriate.
> 
> This need to have MythTV both built and installed is handled in Gary's 
> script by using 'mock' in chain mode.  There have been problems 
> historically but it's working now.  mock also makes it possible to 
> cross-compile for other repos - but of course there are likely to be 
> differences in the names and properties of the packages that need to be 
> pulled in to do the builds, and the spec files will need to reflect that.
> 
> https://github.com/garybuhrmaster/packaging/commit/e4903001868e8317cfa5c9be34914e69fc6f802c

That's really interesting. Somehow, I'd forgotten about Gary's script. 
What's most interesting to me is that it uses the approach of a second 
spec file to build the plugins, relying on mythtv-devel. I was 
considering doing that, but was worried it might not work or might be 
"not the done thing" for package development. This proves it works and 
legitimises the approach.

I'd forgotten the problem of the install phase potentially polluting the 
build host, although it had occurred to me. Good to know that use of 
mock can avoid that. For me, I may not need to, because I'm targetting a 
local build service, which I think isolates the host.