[mythtv-users] Packaging common SVN revisions for multiple distros (was Re: Syncing Minimyth with a backend)

[Michael T. Dean]

On 03/16/2008 12:46 PM, Mike Perkins wrote:
> I should have added to my OP: Since the Minimyth distribution does not contain 
> back end code, and Mike Dean says all systems should be built from identical 
> code, this makes connecting any Minimyth box to any back end quite awkward.

As Myth now has many more safeguards to prevent users from running 
incompatible components together, users who wish to use packages from 
various distributions may find it increasingly difficult to find 
compatible packages.  (Or, in truth, they may find it more obvious that 
there exist incompatibilities that they may not have even known existed 
in previous versions of Myth.)

Therefore, I have a question for the packagers.  Since I know nothing of 
the packaging process and since I'm not really in a position to help 
with this plan (as I'm not a package user), feel free to ignore my 
suggestion if it doesn't make sense or if it causes more work for the 
packagers.

I was wondering whether packaging would be more difficult if someone :) 
were to maintain a list of "recommended revisions for packaging," which 
could be used by packagers from various distributions to choose an SVN 
revision to package.  This someone would be a volunteer who, ideally, 
follows the -commits and/or -dev lists or who--if nothing else--hangs 
out enough in IRC to be notified of "important" changes that may warrant 
a new package.

The list would be a list of 0.21-fixes and/or trunk SVN revisions from 
which packagers could choose when building a new package.  Ideally, 
there would enough revisions chosen for the list to allow packagers to 
provide updates as frequently as desired, but not so many that the list 
is irrelevant.  Packagers wouldn't need to create a package for each 
revision on the list, but by choosing a revision from the list, 
packagers would make it much easier for users to find /known/ compatible 
revisions (=same revision) even when using multiple distributions.

If, for example (all made up numbers, no offense intended), Ubuntu and 
ATrpms want to have a weekly build from 0.21-fixes SVN, and other 
distributions (such as SUSE, KnoppMyth, MiniMyth, XBox-Myth (sorry, 
don't know the name), etc.) wanted less frequent builds, then the list 
should contain one SVN revision per week.  Users who choose to use 
multiple distributions could then find the most recent revision packaged 
by all distros they use.  So, for example, even if one distro had new 
builds once per month and another did weekly builds, the user would be 
able to select a build for both distros that uses an identical SVN 
revision and is less than a month old.  (I'm imagining this list would 
be maintained on the wiki and that a table could show which distros 
built which revisions.  The table could be filled in by users of 
distros, rather than by the person maintaining the list of revisions.)

For those distros providing bleeding/experimental/whatever packages 
built from trunk, the same could apply.  A separate list of trunk 
revisions could be maintained for those packages.

Of course, this whole plan hinges not only on packager acceptance 
(itself hinging on my assumption that this wouldn't really create extra 
work for packagers) but also on someone's volunteering to maintain the 
list.  In addition, if a distro creates packages more frequently than 
other distros, it assumes that users will be able to upgrade to some 
other-than-the-newest build (which may mean keeping a few builds 
around--if it's even possible for a user to choose "how far" to upgrade).

Thanks,
Mike