[mythtv] Building MythTV SVN Packages (rpm)

Chris Petersen lists at forevermore.net
Wed Apr 5 08:04:37 UTC 2006

> I put it there.  Isaac told me too, as he wasn't having anything to do with
> putting it in the source tree (even in contribs folder), as we are all
> aware.

I can understand why he wouldn't want a subversion build spec in the 
source.  Maybe I'll bug him about a release spec again someday -- I 
personally would like to see all software out there be able to have 
packages built straight from the release tarball.

>> Plus, the one I was referring to earlier is not the svn one, 
>> but my build-from-release one that whoever made the original 
>> svn one used as his starting point.
> "whoever" - that was me.  :-)

didn't realize that.  nice job/idea, even if it did start this 
interesting argument/discussion.  :)

> Guys, it's quite simple really...  Your two non-svn .spec files functionally
> aren't actually that different.  Yes, they LOOK very different, but that's
> mostly just whitespace and comments that Chris hass gone and added, and
> which I for one found most useful. 

That's what I've been trying to say.  The core difference in my spec is 
that I pulled out the configure options and documented them.  I also 
replaced the "run perl in sed mode" with straight calls to sed (it just 
seemed silly not to, especially since there were some straight sed 
calls, too, and being consistent is good).

Any updates that Axel has in his that weren't in mine are purely because 
mine worked for me.  Heck, the ones posted on my website don't really 
even look like the ones I'd been using before writing the svn spec.  I 
don't consider those "published" software so I don't update the posted 
ones with every little change I make.

> I agree.   I don't see a problem with atrpms releasing "releases", and SVN
> users using SVN sub-releases....it's only going to be interesting if either
> atrpms starts doing SVN versions, or the very SVN oriented .spec in the wiki
> is used for releases, and even then, the package numbering isn't ever going
> to conflict directly, so it's still a non-event.

I originally designed the version numbering in my spec so it wouldn't 
conflict.  SVN versions are "next"..  meaning that since the current 
release is .19-1, the svn version is .20-0.12345 (or whatever).  When 
.20 comes out, atrpms will release a .20-1 package that overrides the 
svn package if users don't want to continue using svn.  Aside from the 
practical reasoning for this, upstream development has agreed that 
"trunk" *is* .20-in-development -- that's why there's a separate branch 
for fixes to the current release.

If atrpms starts releasing svn packages again (which I still think is a 
great idea), my guess is that they'll be revisioned in a similar 
fashion.  Users shouldn't be particularly confused about things because 
a revision is a revision.  There shouldn't be any patches applied to a 
subversion packages, anyway, or it would taint the whole point of using 
svn for bug testing.

> Personally, I'm happy to see ANY changes made to the one in the wiki that
> improve it's usability for developers, or make it's packaging more
> "correct".... (where "correct" COULD be defined as 'like atrpms do it' if
> there is no other reason to do it a particular way)

I couldn't find a correct way to make the svn package do its own 
checkout.  I just wanted to fix Buzz's spec so I didn't have to run 
rpmbuild two or more times every time I wanted to build a package.

> You'll notice.... I've never distributed a rpm/srpm based on these spec
> files, and I din't think Chris is either.  :-)

And I never will.  On the other hand, I am happy to work with anyone who 
wants to use my spec to do so (for releases, not for svn), which is why 
I've been helping livna develop a mythtv package (which I think will 
suck, btw, since they refuse to enable useful options like xvmc because 
of patent stuff).


More information about the mythtv-dev mailing list