[5406] in Release_7.7_team
Re: Dev framework for modified RPMs
daemon@ATHENA.MIT.EDU (William Cattey)
Mon Jan 30 23:16:22 2006
In-Reply-To: <200601302354.k0UNsiSK015046@egyptian-gods.mit.edu>
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <69d39f331ae756e3abdd378d126a32cd@mit.edu>
Content-Transfer-Encoding: 7bit
Cc: release-team@mit.edu
From: William Cattey <wdc@MIT.EDU>
Date: Mon, 30 Jan 2006 23:16:15 -0500
To: Greg Hudson <ghudson@mit.edu>
X-Spam-Score: 3.263
X-Spam-Level: *** (3.263)
X-Spam-Flag: NO
The course of action you outline sounds quite sane.
I particularly like how you're taking the opportunity to pilot a new
approach, but doing so in a way that gives you an exit strategy back to
the old approach.
-wdc
"Like my father before me, I shall remain 5 years old till the day I
die!"
On Jan 30, 2006, at 6:54 PM, Greg Hudson wrote:
> Recently, I wrote about the need for a development discipline for
> maintaining sources based on modified RPMs:
>
> This mostly means a script for running "rpmbuild -bp" on an SRPM
> and importing the result into a version control system.
>
> The version control system could be the Athena CVS tree, or a new
> Subversion repository for each package. I can think of arguments
> for either.
>
> Here are the arguments on each side. For CVS:
>
> * Our existing CVS tree is already set up and we know how to use it.
>
> * It keeps more of our sources in one place.
>
> * Using Subversion would require using a tool like svn_load_dirs.pl
> or svk to do the imports, since Subversion doesn't have a native
> function for repeated imports. (svn_load_dirs is in the
> Subversion contrib directory and is pretty straightforward,
> though.)
>
> For Subversion:
>
> * I'd like to be piloting Subversion in more contexts, and this is a
> low-risk way of doing so.
>
> * Subversion may do a better job of keeping the diffs against the
> vendor branch clean, due to quirks in CVS.
>
> * This stuff will not be built by build-all.sh, so it arguably
> doesn't belong in the main Athena tree.
>
> I'm going to head down the Subversion road for now, but the resulting
> script will likely be easy to convert to use CVS if we change course.
> The bulk of the work writing the script will be figuring out the least
> obtrusive way of converting an SRPM into an importable source tree.
