source=() parsing in the AUR

karol · 2013-06-06 20:48:32

It's not a huge deal, but is there something that can be done about output like this:
https://aur.archlinux.org/packages/aurqt/

Sources
-c1/aurqt/aurqt-0.2.1.tar.gz
aurqt
cut
http://pypi.python.org/packages/source/
|

https://aur.archlinux.org/packages/au/aurqt/PKGBUILD

Xyne · 2013-06-06 20:52:39

Ah, the joys of abusing Bash in PKGBUILDs.

HalosGhost · 2013-06-06 20:59:34

I haven't found one. I have a similar problem in the source arrays of some -git packages. I'd prefer to just have pkgname=name-git and then, in the source array, use "${pkgname//-/.}", but it leads to some ugly source listings on the AUR, so I avoid it.

All the best,

-HG

progandy · 2013-06-06 21:30:15

This PKGBUILD should at least use bash string manipulation instead of cut: ${_pyname:0:1}

karol · 2013-06-06 21:31:20

progandy wrote:

This PKGBUILD should at least use bash string manipulation instead of cut: ${_pyname:0:1}

Would it make the source output saner?

progandy · 2013-06-06 21:37:03

karol wrote:

progandy wrote:
This PKGBUILD should at least use bash string manipulation instead of cut: ${_pyname:0:1}
Would it make the source output saner?

I believe so. I know I saw PKGBUILDs using that, but I don't remember whether it was in the ABS or AUR.

HalosGhost · 2013-06-06 23:08:00

Well, it will show less sources, but they won't be more sane. That's the scenario I mentioned earlier.

All the best,

-HG

karol · 2013-06-07 15:02:00

Unfortunately seems it can't be fixed atm https://bugs.archlinux.org/task/25210 (somehow missed that report ;P)

Earnestly · 2013-06-08 11:12:26

You don't need to mangle pkgname at all. Really.

pkgname=foobar-git

source=("$pkgname"::git://url)

build() {
    cd "$pkgname"
    ...
}

I wish people would stop doing it.

Lone_Wolf · 2013-06-08 11:21:29

frankly, this problem looks like some people don't know where to stop.
I've checked the real source url and i don't really understand why all that string processing is needed.

https://pypi.python.org/packages/source/a/aurqt/aurqt-0.2.1.tar.gz

it could be written as :

source=(https://pypi.python.org/packages/source/a/${pkgname}/${pkgname}-${pkgver}.tar.gz

no string manipulation needed at all, easily human readable at the cost of 1 additonal hardcoded part of the source url.

karol · 2013-06-08 11:23:02

Lone_Wolf wrote:

at the cost of 1 additonal hardcoded part of the source url.

I think maintainers are trying to avoid that.

Lone_Wolf · 2013-06-08 11:29:52

i understand that, and speaking in general agree with it.
However the first part of the url is hardcoded anyway, this means that sources from pypi need a (small) onetime manual change to check the hardcoded part is correct when the pkgbuild is created.
And you need to verify the source url is correct anyway when creating a new package.

is it really worth it ?

karol · 2013-06-10 01:35:42

I found a really cute one: https://aur.archlinux.org/packages/mplayer-mt-lite/ :-)

Dependencies (32)
    -Q
    -Q
    -Q
    -Q
    2>/dev/null
    2>/dev/null
    2>/dev/null
    2>/dev/null
    awk
    awk
    awk
    awk
    faad2
    ffmpeg-mt-lite
    libass
    libdvdread
    libgl
    libjpeg
    libmad
    libpulse
    libxss
    libxv
    libxvmc
    smbclient
    {print
    {print
    {print
    {print
    |
    |
    |
    |

WorMzy · 2013-06-10 01:56:14

Oh dear lord. How did you find that monstrosity?

In my opinion, PKGBUILDs should define clearly what they need to build. None of this "if alsa's installed, include it as a dependency rubbish.

Also, people should use clean chroots to build packages, and amend their PKGBUILDs as required, but that's probably asking too much.

karol · 2013-06-10 02:13:39

WorMzy wrote:

Oh dear lord. How did you find that monstrosity?

I found it by chance a long while ago, comparing different mplayer PKGBUILDs in the AUR. It's a different case from https://aur.archlinux.org/packages/aurqt/ , which may now be considered a milder issue ;P

HalosGhost · 2013-06-10 04:27:50

The only time conditional dependencies should be a thing (imho) is when you have something like the following:

depends=('alsa-lib')
[ "$CARCH" == 'x86_64' ] && depends+=('lib32-alsa-lib')

That way you have sensible dependency resolution for both x86 and x64 architectures. But, I'm with you karol, conditional dependencies based on installed packages seems non-sensical to me.

All the best,

-HG

Scimmia · 2013-06-10 04:31:40

I can see it. A lot of times the build system will autodetect what's on the system and build in support for that. Usually that means you end up with deps that aren't listed, this is a method of getting them into the dep list.

Not saying it's a good idea, just that I can understand why someone would do it.

Last edited by Scimmia (2013-06-10 04:32:29)

HalosGhost · 2013-06-10 04:34:21

Scimmia wrote:

I can see it. A lot of times the build system will autodetect what's on the system and build in support for that. Usually that means you end up with deps that aren't listed, this is a method of getting them into the dep list.
Not saying it's a good idea, just that I can understand why someone would do it.

But wouldn't that just be easier to handle as opt-depends, or in a configure script rather than awk'd conditional dependencies?

All the best,

-HG

Scimmia · 2013-06-10 04:37:39

optdepends don't keep deps from being uninstalled, plus they tell you nothing about what was built into the program since their presence really only matters at build time.

I'm thinking that a check and then using depends+= wouldn't actually be too bad of an idea

HalosGhost · 2013-06-10 04:39:12

A Fair point. Unrelated: congrats on breaking the 1k post mark

All the best,

-HG

Scimmia · 2013-06-10 05:11:37

Thanks! One or two of them have even been useful.

josephg · 2013-06-16 12:12:11

For what is worth, I managed to hide some bash scripting in this PKGBUILD i maintain: https://aur.archlinux.org/packages/counter-strike-2d/

Arch Linux

#1 2013-06-06 20:48:32

source=() parsing in the AUR

#2 2013-06-06 20:52:39

Re: source=() parsing in the AUR

#3 2013-06-06 20:59:34

Re: source=() parsing in the AUR

#4 2013-06-06 21:30:15

Re: source=() parsing in the AUR

#5 2013-06-06 21:31:20

Re: source=() parsing in the AUR

#6 2013-06-06 21:37:03

Re: source=() parsing in the AUR

#7 2013-06-06 23:08:00

Re: source=() parsing in the AUR

#8 2013-06-07 15:02:00

Re: source=() parsing in the AUR

#9 2013-06-08 11:12:26

Re: source=() parsing in the AUR

#10 2013-06-08 11:21:29

Re: source=() parsing in the AUR

#11 2013-06-08 11:23:02

Re: source=() parsing in the AUR

#12 2013-06-08 11:29:52

Re: source=() parsing in the AUR

#13 2013-06-10 01:35:42

Re: source=() parsing in the AUR

#14 2013-06-10 01:56:14

Re: source=() parsing in the AUR

#15 2013-06-10 02:13:39

Re: source=() parsing in the AUR

#16 2013-06-10 04:27:50

Re: source=() parsing in the AUR

#17 2013-06-10 04:31:40

Re: source=() parsing in the AUR

#18 2013-06-10 04:34:21

Re: source=() parsing in the AUR

#19 2013-06-10 04:37:39

Re: source=() parsing in the AUR

#20 2013-06-10 04:39:12

Re: source=() parsing in the AUR

#21 2013-06-10 05:11:37

Re: source=() parsing in the AUR

#22 2013-06-16 12:12:11

Re: source=() parsing in the AUR

Board footer