[SOLVED] NASM or YASM in PKGBUILD 'depends'

wwgfd · 2015-01-16 09:48:25

I have adopted the AUR package for OpenH264.
-- I have never submitted or maintained an AUR package before so please bear with me.

The package requires NASM to build, however YASM provides support for this and more.
The package built fine on my machine using YASM so I was wondering which I should list in the PKBUILD's "depends" field?
-- it seems likely to me that more people will already have YASM installed and/or it is more common or popular these days?!

Thanks for any advice

Last edited by wwgfd (2015-01-20 12:06:33)

Lone_Wolf · 2015-01-16 15:30:12

I think in this case Arch 'keep packages as vanilla as possible" attitude (not sure if it's an official policy) might help.

If upstream says NASM is needed to build, then list NASM as dependency.

Raynman · 2015-01-16 16:20:11

Or put them both in the PKGBUILD on separate lines, one commented out, and add a short note saying either should work.

wwgfd · 2015-01-16 19:45:00

Hi, thanks for both of your replies. I have updated the package now.

@Lone_Wolf -- I understand your point and yes I somewhat agree, however for the meantime (since that is what I used) I have left it using YASM for it's dependency.

@Raynman -- I did take your advice though and added a comment stating that NASM was the official dependency of the source, but that YASM works as an active replacement.

I still need to knock the PKGBUILD script in to a better shape, although it will suffice for now, so please feel free to offer your critique / advice.

-- Thanks again!

Lone_Wolf · 2015-01-17 12:24:37

provides=("$_pkgname") should be provides=("$_name")

Also you're trying to combine old-style VCS download method (pre-pacman 4.1) with current method.

try source=('https://github.com/cisco/openh264.git#branch=openh264v1.3') , chances are big you won't need anything in prepare then.

see VCS_PKGBUILD_Guidelines and man PKGBUILD .

wwgfd · 2015-01-18 15:24:55

Thank you @Lone_Wolf

I tried the updated VCS method as per your example but it only seems to download a html file (filename='openh264.git') in to the PKGBUILD directory, and places a sym-link to this file in the 'src' folder. It does not appear to actually initiate a clone/update of the repo!

Am I missing something or should I be manually putting the code to clone the repo in to the 'build()' statement?
(i.e. if I were to remove the 'prepare()' statement as you suggest)

If I'm understanding the wiki page correctly then the newer versions of Pacman (>=4.1) support cloning a repo automatically:

"...makepkg will clone/checkout/branch the repository into $SRCDEST ... and copy it to $srcdir ..."

----------------

I am also having trouble with the 'pkgver()' function -- I discovered that this was because initially I was using a shallow clone (i.e. "git clone --depth 1 ...") when I still had the 'prepare()' function in the script.

Should I be forcing a shallow clone?
-- it always annoyed me when packages 'force' a full-checkout when usually the historical data isn't necessary for building the package, especially when the package is of a large size and/or with a lengthy history.

----------------

Again thanks for all help and advice!
-- I will update and bump the release once I have sorted these issues out

Lone_Wolf · 2015-01-18 22:22:49

I do remember there was a discussion about shallow clones or not when pacman 4.1 introduced VCS options for sources array.
a choice was made not to use shallow clones.
Search in the arch-dev or arch-general mailing list archives to find out more.

-------------------------

I tried the updated VCS method as per your example but it only seems to download a html file (filename='openh264.git') in to the PKGBUILD directory, and places a sym-link to this file in the 'src' folder. It does not appear to actually initiate a clone/update of the repo!

This may be due to changes in pacman 4.2 that bring vcs source handling much closer to those for tarball sources.

Try this option :

man makepkg wrote:

-C, --cleanbuild
Remove the $srcdir before building the package.

-----------------------------
Shallow clone : if you do want to stick to a shallow clone, use the manual download code, and remove the vcs link from source array.

Last edited by Lone_Wolf (2015-01-18 22:23:15)

progandy · 2015-01-18 22:50:02

Shallow clone : if you do want to stick to a shallow clone, use the manual download code, and remove the vcs link from source array.

Maybe we could add some additional fragment options for shallow clones and single-branch clones, e.g.
git://some.git#shallow#tag=...
git://some.git#singlebranch#branch=...

If I can get some good idea how to do it I'll send a request to the mailing list.

Last edited by progandy (2015-01-18 22:51:30)

wwgfd · 2015-01-20 01:24:33

Hey thanks for all the help and suggestions, I got there eventually...

source=("$pkgname::git+https://github.com/cisco/openh264.git#branch=master")

Previously I hadn't put the 'git+' part in this line because I'd assumed (incorrectly?) that the '.git' suffix of the URL counted as 'reflecting the VCS type', as per the criteria given on the VCS_package_guidelines wiki page:

vcs+ is needed for URLs that do not reflect the VCS type, e.g. git+http://some_repo.

After adding the vcs+ prefix the source downloaded just fine!
-- I realised that what I had been getting before was a wget fetch of the project's GitHub web page rather than the actual git repo (doh!)

----------------

The 'pkgver()' method works again too and has updated the version to reflect the git revision number(s) etc. so the version number now stands at: 'v1.3.r145.g8bef6bc'.

However I had pre-empted eventual success and already set 'pkgrel=2' in my PKGBUILD, but after running makepkg this was reset to '1'
-- Should I set it back to '2' before I uplo ... sorry, brainwave hit me mid sentence ...

I might just be able to answer my own question here (or rather the question I was about to ask) ...

In working my way through this little issue I decided that it would be simpler to let this package reflect the 'master' branch rather than the 'v1.3 release' branch. As such (I realise now) the new PKGVER number is correct and reflects the fact that the package has been updated, and since it is now referencing a new source (branch) the updated PKGREL number is also correct and should indeed be '1'!

-- I hope I got that right

[ Edit: I also found the info on Allan McRae's website about 'Changes To VCS Packaging Support In Makepkg' helpful to read! ]

Last edited by wwgfd (2015-01-20 01:28:41)

Allan · 2015-01-20 03:26:41

#branch=master

is not needed.

wwgfd · 2015-01-20 12:01:55

@Allan -- Thanks, you're right. However I think I will leave it in, it works and is more explicitly clear for anyone reading the PKGBUILD.

Arch Linux

#1 2015-01-16 09:48:25

[SOLVED] NASM or YASM in PKGBUILD 'depends'

#2 2015-01-16 15:30:12

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#3 2015-01-16 16:20:11

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#4 2015-01-16 19:45:00

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#5 2015-01-17 12:24:37

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#6 2015-01-18 15:24:55

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#7 2015-01-18 22:22:49

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#8 2015-01-18 22:50:02

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#9 2015-01-20 01:24:33

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#10 2015-01-20 03:26:41

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

#11 2015-01-20 12:01:55

Re: [SOLVED] NASM or YASM in PKGBUILD 'depends'

Board footer