fedpkg prep

[Steve Dickson]

On 08/31/2010 07:51 PM, Jesse Keating wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 8/31/10 4:45 PM, Jesse Keating wrote:
>> On 8/31/10 3:48 PM, Steve Dickson wrote:
>>> Just curious....
>>
>>> Why does 'fedpkg prep' care that the repo is in an inconsistent state?
>>
>>> I just did a rebase to the latest f14 code on a private branch. 
>>> So yes he repo in an inconsistent but that is ok. I'm going to
>>> make some changes to put it back in a consistent state but 
>>> I can not do that without a source tree.
>>
>>> So is there a way to do what the old 'make prep' did? That is
>>> stupidity untar the tarball an apply all the current patch 
>>> without checking any state??
>>
>>> tia,
>>
>>> steved.
>>
>>
>> It only cares in that the "prep" function is a function of the
>> PackageModule class.  When we create an object of the PackageModule
>> class, we also create an object for the git repo.  It's when trying to
>> create the object for the git repo that git is returning us an error,
>> which we are passing along.  It doesn't have anything to do with "prep"
>> itself, any action which would necessitate creating the PackageModule
>> object would run into this issue.
>>
>> Couple things I've been thinking about.  We could delay creating the git
>> object unless calling a function that requires it.  We could move some
>> of the rpm commands out of the PacakgeModule class.  We could catch this
>> and not care unless we are doing a git action.
>>
>> Either way, in this case your git repo does seem kinda broken, and you
>> might want to fix that.
>>
> 
> Ah, in this case we do need info from the git repo, such as which branch
> you are on, so that we can correctly fill in the macros that might be in
> the spec such as %{?dist}, %{?fedora}, %{?fc14}, etc..  So yeah, I don't
> know if I can actually "fix" this particular issue.
I guess I don't understand why all this state is needed to simply
lay down the tar ball and apply the current patches... The tar ball
and patches have nothing to do with the version of Fedora or 
the state of a repo... To me, it seems like such a simple process 
that state or objects or whatever should not be needed... 

steved.