[mythtv-users] different versions on frontend and backend

[Bryan Halter]

Michael T. Dean wrote:

> Robert Johnston wrote:
>
>> On 30/10/05, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>>  
>>
>>> Robert Johnston wrote:
>>>   
>>>
>>>> Incorrect. You can pass --disable-frontend and/or --disable-backend if
>>>> you want to make a FE-Only or BE-Only machine.
>>>>
>>> Yeah, if you don't want it to build.  Those are porting only
>>> options--they are /not/ valid options on Linux.  See
>>> http://svn.mythtv.org/trac/browser/trunk/mythtv/configure?rev=7650 
>>> lines
>>> 2740 and 2747--and especially lines 2741 and 2748.
>>>   
>>
>> These USED to be valid options to build a front-end only system (As it
>> seems very wasteful to have to build the whole of the backend, just to
>> never use it, especially on something like an XBOX-frontend, which
>> will NEVER be able to offer backend functionality, and building the
>> binaries (As well as keeping them) will only waste CPU time and HDD
>> space).
>>
>> These were changed in Rev. 7577 to add the warnings mentioned above,
>>  
>>
> Right, but the warnings were added because of the sheer number of 
> posts/tickets where people reported that they couldn't build their 
> "lightweight" MythTV system using "--disable-backend" or 
> "--disable-frontend".
>
> Here's the commit message where the options were first added.  Note 
> the "so it should be considered as something useful only for porting 
> the backend," and "The basic aim here" parts.
> http://www.gossamer-threads.com/lists/mythtv/commits/136628#136628
>
>> and TBH I think changing this breaks the whole "Client-Server"
>> functionality that Myth is supposed to be promoting, with independant
>> multiple frontends and multiple backends. It used to be that a backend
>> machine didn't require the behemoth that is X to compile, or run, but
>> with these dependancies, it makes what should be a small(er) program
>> with only the dependancies on what it needs become a huge thing that's
>> not efficient at all.
>>  
>>
> AIUI, Isaac has (rightly, IMHO) taken the stance that a "few" extra 
> megabytes of installed applications on a system that processes 
> multi-gigabyte files does not provide sufficient cause to justify the 
> work entailed in separating the two such that each is completely 
> independent of the other.  If you really want that lightweight 
> frontend or backend, though, feel free to submit patches.  ;)
>
>>>>> As a matter of fact, the same applies to
>>>>> mythplugins--you need the same version of mythplugins as the 
>>>>> version of
>>>>> mythtv.
>>>>>
>>>> That's also incorrect. MythPlugins have to be built against the same
>>>> version of libMyth, but you can take an old version of the plugins
>>>> source, as long as it's built against the same version of libMyth as
>>>> the MythFrontend you are wanting to load them from.
>>>>
>>> Unless there are changes that break compatibility.  This includes
>>> incompatible changes to the myth protocol version, the DB schema
>>> version, the libraries used by the plugins (i.e.
>>> http://svn.mythtv.org/trac/ticket/531 ), and ...
>>>   
>>
>> In thoery, each "Plugin" should handle it's own "DB Schema", as they
>> should be interchangeable. IOW, MythWeather should not be touching
>> MythVideo's DB entries, and MythTV should not be changing MythNews'
>> schema.
>>
>> This would mean that you could mix-and-match between Plugins/MythTV
>> versions, with no compatibility issues.
>>  
>>
> Yes, but MythWeb is actually more of a completely independent frontend 
> than a "plugin," so it /requires/ knowlege of the DB schema.  This is 
> actually why the current MythWeb can corrupt custom recording rules 
> and other features new to the DB schema--it hasn't yet been completely 
> updated for some of the changes.
>
>>> And, in /all/ cases, doing so is *not* a "supported"
>>> configuration--which was the point I was trying to make.  Unless, of
>>> course, you're volunteering to provide support for all possible version
>>> combinations users may wish to try.
>>>   
>>
>> Now, I'm not going that far. But you *should* be able to compile a
>> backend-only system without anything breaking, as it's meant to work
>> independantly of any frontends that may be attached to it. Likewise
>> with the Frontend-Only compilation. If there is functionality that is
>> used in both the frontend and backend, it should be modularised so it
>> can be used in both independantly (Moved into libmyth, perhaps?).
>>
>> Otherwise, there's not much point in having seperate front-end and
>> back-end programs, and the whole thing might just as well be one
>> massively-threaded monolithic program.
>>
>> My £0.02 ($0.0355157USD)
>>
> IMHO, having the mythbackend on disk on my frontend or the 
> mythfrontend on disk on my backend is not a big deal, but being able 
> to run mythbackend without starting mythfrontend or vice-versa is 
> critical.
>
> As for breaking the client/server functionality, it's hard enough 
> getting people to understand what they do and don't need with just a 
> "mythtv" program that gets installed on all their Myth 
> boxes--regardless of whether they're dedicated backends or dedicated 
> frontends or combined frontend/backend boxes.  I can only imagine how 
> complex this would get with mythfrontend, mythbackend, and 
> libmyth--and people trying to use varying versions of mythlib with 
> mythfrontend/mythbackend/mythplugins/whatever.
>
> I'll admit it could be made a more elegant solution, but I'd rather 
> have new features like mythui or mfd than an opportunity to save 100MB 
> storage space (which is enough space for about 6 minutes of relatively 
> low-quality video ;).  Even if it turned out to save 500MB, I don't 
> see the value in the savings.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
Hi I'm Bryan and I'm a Gentoo freak

<dawns flame proof suit>

I like being able to have a BE only system without X and the like 
because its less maintenance especially since to build the FE I not only 
need X, but Qt, some dm, and other assorted libraries.  For a system 
that runs a process in the background that's a lot of cruft to have 
floating around.  It is true that I have gobs of disk space available 
and adding those extra libraries isn't a big deal but it has the ability 
to create dependancy hell, an example being last spring's DST bug in 
Qt.  If I had other software that used Qt and needed the newer version I 
would have been in trouble since for a few days the only available work 
around was 1) a hack or 2) downgrade Qt.  Fortunately I was able to 
downgrade Qt.  Now if for some reason Myth has a dependancy on some new 
verison of Qt and I have other GUI apps running on that system that rely 
on deprecated functionality/bugs it would be nice to be able to build BE 
only and not have to upgrade Qt because the FE which will never be used 
depends on it.

</flame proof suit>

I do realize if I want it I am free (as in speech) to submit a patch.

Just my $.02

--Bryan