[pacman-dev] [PATCH] makepkg: Add warning if VCS tool is not present when determining latest VCS revision

Allan McRae allan at archlinux.org
Sun Jun 26 19:47:15 EDT 2011


On 25/06/11 22:45, Eric Bélanger wrote:
> On Sat, Jun 25, 2011 at 6:18 AM, Allan McRae<allan at archlinux.org>  wrote:
>> On 25/06/11 14:31, Eric Bélanger wrote:
>>>
>>> Signed-off-by: Eric Bélanger<snowmaniscool at gmail.com>
>>
>> Signed-off-by: Allan
>>
>> However, note this is one of the crap things about the current VCS
>> implementation.  devel_check is run before the installation of makedepends
>> so this many result in people getting warnings when running makepkg for the
>> first time but not the second...
>
> Yeah. My initial intention was to move these checks in the
> check_software function but, after that patch was done, I realized
> that devel_check would fail if the VCS tool was missing.  Changing the
> warning message to error would've make it imposible to build these
> package in a clean chroot so that wasn't a good solution.  In the end,
> I decided to make this patch so my work woudn't be lost. I also
> checked the VCS bugs and it's messy.
>
>> Apart from the planned (for long a time)
>> rewrite of all of this, I'm not sure there is much else to do here.
>
> I might be overlooking something, but why don't we just install the
> required VCS package? Instead of the warnings in my patch, we could
> have a message like "Installing git to determine latest git revision"
> then do a 'pacman -S git' and so forth.  As the VCS tool will be in
> the makedepends anyway the inconvenience of that method would be
> minor, if any.
>

I'd prefer not to have pacman install anything unless -s is specified 
and then it needs to be cleaned up with -r.  So it is slightly more 
complicated than that.

In the end, this will be less of an issue once we get around to dealing 
with those patches that allowed something like:
source=("git@@http://git.repo.com...)
as then we can do the check in check_software.

I have pulled the patch as-is to my working branch.

Allan


More information about the pacman-dev mailing list