AUR web frontend sources URL problem

mykhal · 2007-09-02 17:26:06

Sometimes the $pkgname is different from source package tarball filename, so it is necessary to use a different variables.. For an imaginary foo package, with sources available at http://foo.org/foo-linux-1.2.tar.gz , the PKGBUILD fragment may look like

...
pkgname=foo
pkgname0=foo-linux
pkgver=1.2
source=('http://foo.org/$pkgname0-$pkgver.tar.gz')
...

unfortunaly, in such case, the AUR web page points to a wrong sources URL: http://foo.org/foo0-1.2.tar.gz . It looks like the frontend thinks that the source URL must contain $pkgname, and is doing simple string substitution, not interpreting the PKGBUILD as a shell script.

Is there already a working way how to form the PKGBUILD, to avoid this sort of problem ?

Last edited by mykhal (2007-09-02 17:28:50)

dolby · 2007-09-02 17:42:02

use source=('http://foo.org/$pkgname-linux-$pkgver.tar.gz')
or source=('http://foo.org/foo-linux-$pkgver.tar.gz')
or any other way that'll make the pkgbuild download the sources is acceptable

mykhal · 2007-09-02 17:44:48

thanks, this is so simple and obvious solution, so that it even didn't come to my mind.. :]

mykhal · 2007-09-02 18:10:25

However, this fix follows KISS principle, but not DRY, because the alternate package name also has to be used in build() again.

cactus · 2007-09-02 18:32:56

some people use $_altname and things like that.
I don't know how I feel about it though.

DRY is only really valid in cases where you are duplicating OFTEN or EXCESSIVELY.
Two or three instances of manually typing the name is, in my opinion, not repetitive enough to violate KISS.

mykhal · 2007-09-02 18:51:31

cactus wrote:

some people use $_altname and things like that.
I don't know how I feel about it though. ...

It does not matter if one uses $pkgname0, $pkgname_ or $_pkgname, the URL is always wrong, see e.g. http://aur.archlinux.org/packages.php?d … 1&ID=11270

I think it should be fixed in AUR web frontend, because it cripples sources URL in many cases.

Dusty · 2007-09-02 19:07:10

I agree that this is an AUR bug. The workaround dolby suggested is certainly fine for the interim, so its not a high-priority bug. I would suggest reporting it to the bug tracker, but apparently its "down for maintenance".

Dusty

mykhal · 2007-09-02 19:54:43

OK, the bug, or maybe the fly, is reported. It's #7941, for reference.

mykhal · 2007-09-02 20:54:09

.. by the way, what can someone do, if he wants to have his AUR PKGBUILDs reviewed and flagged as Safe, if he both is not and does not know any TUR ?

Dusty · 2007-09-02 21:26:29

mykhal wrote:

.. by the way, what can someone do, if he wants to have his AUR PKGBUILDs reviewed and flagged as Safe, if he both is not and does not know any TUR ?

Usually TUs get to them eventually, but I don't think they'd be offended if you e-mailed the tur-users list. They might be though, you never know with TUs. They can be an unstable bunch. :-D

Dusty

cactus · 2007-09-02 22:04:04

Dusty wrote:

They can be an unstable bunch.

We should get somebody to flag them 'safe'.

nesl247 · 2007-09-02 22:36:16

Hey I resent that, I'm not unstable! I can't speak for anyone else, but if you email the tur-users ml, I *might* take a look at the pkgbuild, try it, and mark it safe.

Dusty · 2007-09-03 05:05:51

nesl247 wrote:

Hey I resent that

See what I mean? Unstable.

*nods wisely*

:-D

Dusty

tardo · 2007-09-03 05:08:00

Actually, I'd be careful. If you mailed it on the ML, all 28 of us TUs might look at it and then fight over who's going to mark it safe...

nesl247 · 2007-09-03 05:25:09

I will! I will! said nesl247 as he jumped up and down.

mykhal · 2007-09-03 14:35:58

Strange that there are so many volunteers, and my packages are still black instead of being green..

Dusty · 2007-09-03 15:29:03

maybe its not safe. :-D

tardo · 2007-09-03 15:46:54

well how about linking us to your packages, don't make us do all the work =]

mykhal · 2007-09-03 17:42:34

thanks for an interest.. http://aur.archlinux.org/packages.php?SeB=m&K=mykhal

(Edit: oops, K has to be upper case)

Last edited by mykhal (2007-09-03 17:44:12)

tardo · 2007-09-03 18:13:06

Done. Check your pkgbuild pages for comments. MIT licenses require the license to be installed into /usr/share/licenses/$pkgname. custom variables always begin with a _.

I don't think I'll ever flag the openssh pkg as safe because you're implementing completely new functions not found in the official package. Other than that, fix the others and you're good to go =/

mykhal · 2007-09-03 19:08:57

tardo wrote:

...I don't think I'll ever flag the openssh pkg as safe because you're implementing completely new functions not found in the official package. Other than that, fix the others and you're good to go =/

thanks for the review.
If you look more carefully at the openssh patch, it is not implementing anything new, openssh has an infrastructure for using hardware engines (engines.h), but is not used by default somehow, the patch is just enabling it. Anyway, I'm not creator of the patch, is it taken from Michal Ludvig's site (http://www.logix.cz/michal/devel/padlock/) , some of his patches have also been accepted in linux kernel.
But I understand, this is very sensitive package..

mykhal · 2007-09-03 19:16:54

By the way, it's strange that it's required to append '|| return 1' after 'make install', but not after 'python setup.py' .. only 4 of 59 packages in the ABS tree have it.

tardo · 2007-09-03 20:23:15

I think there was a discussion about it some time ago. I prefer to have it because I've seen quite a few packages that continue to build even after install fails. It's more of a personal thing for me since PKGBUILD standards are very lax. Perhaps another TU might mark it safe instead, I for one, won't.

edit: I should probably add, the pkgbuild itself is "safe", but I just prefer compliant pkgbuilds =]

Last edited by tardo (2007-09-03 20:23:59)

Arch Linux

#1 2007-09-02 17:26:06

AUR web frontend sources URL problem

#2 2007-09-02 17:42:02

Re: AUR web frontend sources URL problem

#3 2007-09-02 17:44:48

Re: AUR web frontend sources URL problem

#4 2007-09-02 18:10:25

Re: AUR web frontend sources URL problem

#5 2007-09-02 18:32:56

Re: AUR web frontend sources URL problem

#6 2007-09-02 18:51:31

Re: AUR web frontend sources URL problem

#7 2007-09-02 19:07:10

Re: AUR web frontend sources URL problem

#8 2007-09-02 19:54:43

Re: AUR web frontend sources URL problem

#9 2007-09-02 20:54:09

Re: AUR web frontend sources URL problem

#10 2007-09-02 21:26:29

Re: AUR web frontend sources URL problem

#11 2007-09-02 22:04:04

Re: AUR web frontend sources URL problem

#12 2007-09-02 22:36:16

Re: AUR web frontend sources URL problem

#13 2007-09-03 05:05:51

Re: AUR web frontend sources URL problem

#14 2007-09-03 05:08:00

Re: AUR web frontend sources URL problem

#15 2007-09-03 05:25:09

Re: AUR web frontend sources URL problem

#16 2007-09-03 14:35:58

Re: AUR web frontend sources URL problem

#17 2007-09-03 15:29:03

Re: AUR web frontend sources URL problem

#18 2007-09-03 15:46:54

Re: AUR web frontend sources URL problem

#19 2007-09-03 17:42:34

Re: AUR web frontend sources URL problem

#20 2007-09-03 18:13:06

Re: AUR web frontend sources URL problem

#21 2007-09-03 19:08:57

Re: AUR web frontend sources URL problem

#22 2007-09-03 19:16:54

Re: AUR web frontend sources URL problem

#23 2007-09-03 20:23:15

Re: AUR web frontend sources URL problem

Board footer