[pacman-dev] [RFC] Generation of a .SRCINFO file for source packages

[Allan McRae]

On 29/08/12 07:48, canyonknight at gmail.com wrote:
> On Mon, Aug 27, 2012 at 11:23 PM, Allan McRae <allan at archlinux.org> wrote:
> 
> <snip>
> 
>>> Previous proposal:
>>> The idea of generating a .SRCINFO file was previously proposed on the
>>> mailing list [1]. No format was ever agreed upon and discussion died
>>> off when no fixes were sent based off of developer suggestions. I've
>>> included my own proposed format to fuel discussion and maybe reach an
>>> ideal format.
>>
>> I am composing this offline so have not gone back through the old
>> posts...  but I thought the main issue was that the split package
>> variables are not defined until running the package_* functions.  I.e.
>> we do not know the values of any overridden values unless we actually
>> build the package.
>>
>> This is the main issue that needs solved.
>>
> 
> I believe the previously sent patch [1] was able to extract override
> values set within a package_* function. I think one of the bigger
> issues may have been related to values that are set for a specific
> architecture. I'll rebase the old patch and play around with it to see
> what the issues are.
> 

I can make it break....

package_bar() {
  _url="http://foo.com"
  url=$url/bar
}

Look at how crap our check_sanity function is to see how difficult it is
to do this.


> 
>> So much duplication!  How about just:
>>
>> pkgbase = boost
>> ... (all global values) ...
>>
>> pkgname = boost
>> ... (overrides for boost) ...
>>
>> pkgname = boost-libs
>> ... (overrides for boost-libs) ...
>>
> 
> I'm not a huge fan of having global values in a .SRCINFO file. A
> .SRCINFO parser would have to process globals and then override them
> where appropriate, rather than processing all values directly. There
> is more duplication when global values aren't used, but it makes it
> dead simple for whatever parses the .SRCINFO file. Are globals
> something you would absolutely want in a .SRCINFO file?

No, but I think it makes sense.  There are global values in the PKGBUILD
and they are overridden.  I do not see how there is duplication when the
global values are not used - unless they are unnecessarily put in the
PKGBUILD.

Allan