[mythtv] Building MythTV SVN Packages (rpm)

[Axel Thimm]

On Mon, Apr 03, 2006 at 11:38:56AM -0700, Chris Petersen wrote:
> > I had already discussed this with buzz in PM. Having a specfile use
> > svn co is a very broken concept for rpm, e.g. just like having a
> > specfile use wget to get the release sources. rpm (and deb) go through
> > lengths to ensure deterministic reproducability.
> 
> I'm aware that it's "broken" from a conceptual standpoint.  But for my 
> use, it works great.  I don't like the fact that I have to create a 
> separate tarball for each svn checkout -- it takes a lot of time to 
> compress/uncompress, and takes up extra unnecessary disk space.
> 
> My main concern was to clean up the specs posted to the wiki and to fix 
> what I saw as a really broken solution (that if there was an svn update, 
> you'd have to "build" twice to get the release number correct).
> 
> > This specfile has also desynced quite a lot from ATrpms' partly
> > refixing bugs fixed long ago or fixing bugs w/o submitting these fixes
> > to ATrpms (throwing a complete specfile rewrite with more difflines
> > than the original specfile has doesn't count ;).
> 
> It's been maintained separately from the atrpms packages for my own 
> personal use.  Since it works, I never bothered to update anything to 
> match yours, since it really is just a personal use kind of thing (like 
> any build-your-own svn spec should be).

But the moment it is published on a prominent place like the mythtv
wiki it stops being a personal toy anymore. This encourages users to
actually use it and later wonder why the packages at ATrpms
differ.

This creates issues for both the packager and the developers as it
gets even more confusing as to what svn the user is talking about.

We've been trying to convince Isaac that having CVS/svn packaging is a
good thing, if this starts being a fork war then he'll probably
digress again.

> Maybe I'll have to take a look at what you're doing now and see what
> I can backport into mine.

I'd had preferred if you had considered merging any valuable bits the
other way, but it's your choice.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20060405/a78a1095/attachment.pgp