[pacman-dev] Inconsistency of makepkg's activities in devel_check()

Allan McRae allan at archlinux.org
Tue Aug 18 06:22:11 EDT 2009


Dan McGee wrote:
> On Mon, Aug 17, 2009 at 9:40 AM, Xavier<shiningxc at gmail.com> wrote:
>   
>> On Sun, Aug 16, 2009 at 8:58 PM, Benjamin
>> Richter<webmaster at waldteufel-online.net> wrote:
>>     
>>> Hello developers. :-)
>>>
>>> I noticed that makepkg handles Mercurial repositories differently from
>>> CVS/SVN/Bazaar/etc. With the others, $newpkgver is either computed using
>>> $(date ...) or retrieved from the online repository and the PKGBUILD is
>>> responsible for retrieving the contents as it is demonstrated here:
>>> http://wiki.archlinux.org/index.php/Arch_CVS_%6_SVN_PKGBUILD_guidelines.
>>>
>>> Only with hg the repository is automatically cloned, pulled and updated:
>>>
>>>       
>> I noticed this inconsistency just recently looking at makepkg code,
>> and I don't like it either.
>> I quickly looked at your proposed solutions and I am not convinced (or
>> maybe the first one a) ).
>>
>> My suggestions :
>> 1) cloning in all cases (like a) )
>> one big? disadvantage is that all existing scm PKGBUILDs will have to
>> be converted
>> and I wonder if this method might be too restrictive in some cases,
>> where someone want to clone a repo in a specific way.
>>     
>
> Someone just proposed a patch to actually make GIT more like Hg
> (http://bugs.archlinux.org/task/15895). I'm not a fan of needing a
> full clone to get a version, but we could make it a bit more
> structured and make a specific function like fetch() fire before we
> get a version number? We already have build() and package()...
>   

And likely check() in the future... 
(http://bugs.archlinux.org/task/15145).   Adding a fetch() function 
would allow us to easily fix FS#13727 
(http://bugs.archlinux.org/task/13727), where devel_update() is run 
before checking makedepends. 

 From experience, someone needs to provide a PKGBUILD prototype for us 
to discuss or this suggestion would go nowhere...

Allan




More information about the pacman-dev mailing list