[mythtv] Building MythTV SVN Packages (rpm)
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
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