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

[Paul Gardiner]

On 13/09/2020 15:26, Paul Gardiner wrote:
> 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.

Thinking about this more, long term, I should try moving to Gary's 
script. Either it will just work with OpenSUSE as is, or getting it 
working will be of more general use to people than any bespoke solution 
for a particular distro. At some stage, I hope to look at that.