Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Pacman Development (http://www.linux-archive.org/archlinux-pacman-development/)
-   -   Generation of a .SRCINFO file for source packages (http://www.linux-archive.org/archlinux-pacman-development/698290-generation-srcinfo-file-source-packages.html)

"canyonknight@gmail.com" 08-28-2012 02:23 AM

Generation of a .SRCINFO file for source packages
 
On Mon, Aug 27, 2012 at 8:51 PM, Dave Reisner <d@falconindy.com> wrote:

<snip>

>> - Every variable (pkgver, depends, etc) is preceded by ($pkgname).
>
> I don't like this. Why surround it with parenthesis? pacman in git is
> already fairly strict about what it allows in pkgname=, so if you're
> going to advertise this columnar format, I'd say just leave it
> untouched. (i.e. pkgname="foo bar" won't get past makepkg). The extra
> characters wrapping the name just makes parsing a little more tedious.

My mistake, you are correct parentheses are unneeded thanks to the
strictness of makepkg.

<snip>

> As a counter example, what about the following. Similar to how we do
> the pacman DBs, each package is a "field", e.g.
>
> %PACKAGE%
> pkgname = boost
> pkgver = 1.50.0
> depends = boot-libs=1.50.0
> ...
>
> %PACKAGE%
> pkgname = boost-libs
> pkgver = 1.50.0
> depends = icu
> depends = zlib
> depends = bzip2
> ...
>
> Each section is delimited with a blank line, with the field name telling
> the parser ahead of time what sort of data to expect next.
>

I do think there is a certain nicety to my proposal where any random
line can be parsed and the parser can know the package name and the
variable declaration from that single line. I like your proposal as
well though, and would be more than happy with it. Thanks for your
response Dave.

Regards,

Jason

Allan McRae 08-28-2012 03:23 AM

Generation of a .SRCINFO file for source packages
 
On 28/08/12 07:08, canyonknight@gmail.com wrote:
> Hello all,
>
> I had the idea of adding a .SRCINFO file to source packages generated
> by makepkg. I did some research to see if this had been previously
> proposed and where the discussion went. I've collected my thoughts on
> such an addition for your consideration.
>
> 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.


> Proposed format with example (using "boost" PKGBUILD [2]):
> - Every variable (pkgver, depends, etc) is preceded by ($pkgname).
> - Every "global" (defined outside a package_* function) variable is
> explicitly listed for each $pkgname.
> - Every array (arch, depends, etc) has one line for each array element
>

<snip>
So much duplication! How about just:

pkgbase = boost
... (all global values) ...

pkgname = boost
... (overrides for boost) ...

pkgname = boost-libs
... (overrides for boost-libs) ...


> Advantages of proposed format:
> - Don't need a bash parser to determine PKGBUILD variables in a source
> package. This would make things a lot easier for projects (including
> AUR) that depend on information from PKGBUILD variables.

But you do if you need to extract the values without running a full build.


> Disadvantages of proposed format:
> - Adds additional dot file to every generated source package.

No need to worry about that.


Allan

"canyonknight@gmail.com" 08-28-2012 09:48 PM

Generation of a .SRCINFO file for source packages
 
On Mon, Aug 27, 2012 at 11:23 PM, Allan McRae <allan@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.

<snip>

> 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?

Regards,

Jason

[1] http://mailman.archlinux.org/pipermail/pacman-dev/2010-August/011462.html

Allan McRae 08-29-2012 12:01 AM

Generation of a .SRCINFO file for source packages
 
On 29/08/12 07:48, canyonknight@gmail.com wrote:
> On Mon, Aug 27, 2012 at 11:23 PM, Allan McRae <allan@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


All times are GMT. The time now is 05:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.