You are not logged in.
Could someone help me create a AUR-Package, please?
There is an old, unmaintained AUR for dssi-vst: https://aur.archlinux.org/packages.php?ID=44795
There is a new version here: https://github.com/falkTX/dssi-vst
Would that be a new AUR or just an update for the existing package?
How to make a PCKGBUILD?
Thanks
Last edited by capoeira (2012-12-29 14:03:00)
Offline
How to make a PCKGBUILD?
Bear with me; I'm new to creating PKGBUILDs myself, so I'm sure to be doing something wrong.
First, some links. I found these very helpful for making my own:
https://wiki.archlinux.org/index.php/PKGBUILD
https://wiki.archlinux.org/index.php/Ar … _Standards
What I would do is modify the PKGBUILD in your original link to dssi-vst to update it (update the version and add some code to get it to pull from github; also, rename it to "dssi-vst-git" for clarity's sake). Specifically, have a look at other PKGBUILDs like alsa-plugins-git to see how they handle pulling code from github and then building. The easiest way would be to put the "git clone" in the build() function for the outdated dss-vst plugin and keep the build process mostly the same--example below.
Of course, you'll want to do this manually the first time to make sure you've got the process down. Then you can test your PKGBUILD with "makepkg" to ensure it pulls down the code from github and builds it.
Bonus points: I've noticed that most of the AUR packages that use git tend to have a date (YYYYMMDD) for their version identifier, and it would probably behoove you to do the same. However, they do not appear to snag a specific commit, pulling instead from the master. I'm not sure why this is because I'm more comfortable pulling a known-good commit, but near as I can tell, they don't guarantee that the code they pull is from that version (someone please correct me if I'm wrong). If you wanted to do something a bit more advanced, you could checkout a specific tag or commit to guarantee that your PKGBUILD will build that exact version. Something like this (borrowing again from alsa-plugins-git):
# PKGBUILD-related stuff goes above this line; borrow it from the existing (outdated) PKGBUILD!
_gitroot=git://github.com/falkTX/dssi-vst.git
_gitname=dssi-vst
_gitcommit=122faf0252
build() {
cd "$srcdir"
msg "Connecting to GIT server...."
if [ -d "${_gitname}" ] ; then
( cd "${_gitname}" && git pull origin )
msg "The local files are updated."
else
git clone "${_gitroot}" "${_gitname}"
fi
# Checkout the current tag so we know it's the one that works.
# This does make the repo run in a "detached head" state, but
# for our purposes it shouldn't be a bother.
git checkout ${_gitcommit}
rm -rf "${_gitname}_build"
cp -r "${_gitname}"{,_build}
cd "${_gitname}_build"
# The rest of your build should go here...
}
Again, I'm pretty new to PKGBUILDs, so if I've made a blundering error in my suggestions, I hope someone comes in and sets me straight so that we can get you on the right path.
Edit: Fixed some embarrassing typos.
Last edited by Zancarius (2012-06-14 00:24:10)
He who has no .plan has small finger.
~Confucius on UNIX.
Offline
Bonus points: I've noticed that most of the AUR packages that use git tend to have a date (YYYYMMDD) for their version identifier, and it would probably behoove you to do the same. However, they do not appear to snag a specific commit, pulling instead from the master.
The date in the version is automatically added and updated by makepkg.
If you were to retrieve a specific tag or commit version, the package will still have the YYYYMMDD for the day you build it as version date of the last commit.
There IS a way to have makepkg keep the version number, check man makepkg .
Last edited by Lone_Wolf (2012-06-15 10:02:22)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Online
The date in the version is automatically added and updated by makepkg.
If you were to retrieve a specific tag or commit version, the package will still have the YYYYMMDD for the day you build it as version.
I did not know that. Very interesting and helpful. I haven't yet modified or otherwise put together PKGBUILDs that pull from a git repo, but I'm planning to. I did notice that some of the AUR builds I have update the date upon rebuild, but I had assumed it was a special PKGBUILD flag (that's what I get for assuming!). It's actually good to know that it's automatic and not something that must be specified (and subsequently forgotten).
Thank you for setting that straight! That's really helpful to know.
I'm assuming this is what you meant with keeping the version, if for whatever reason there was a need to hold it at a specific point (such as pulling tags based on a commit):
--holdver
Useful when building development versions of packages. Prevents makepkg from automatically bumping the pkgver to the latest revision number in the package’s development tree.
Edit: I wish I had emphasized this in my post in "why Arch is best." Helpful, friendly extra comments like this really make Arch for me.
Last edited by Zancarius (2012-06-14 21:16:06)
He who has no .plan has small finger.
~Confucius on UNIX.
Offline
Yes, that is correct Zancarius.
I didn't post the part from man makepkg, as that parameter needs to be added manually and can be confusing to users.
Note that i made an error in my post (edited now), the date makepkg uses is NOT the build date, but the date of the last commit.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Online
excuse me, Zancarius
I wanted to try this out the last days, but didn't find the time. I'll come back to this, soon.
just to let you know your post wasn't in vain.
Offline
It's okay! I know how that goes. The last few weeks (save the occasional evening) have been pretty hit-or-miss for me, too.
Be sure to read Lone_Wolf's corrections, too, as my understanding was somewhat mistaken.
I think you'll find making your own PKGBUILDs fairly easy, straightforward, and fun. Plus, if you become interested in maintaining the package, I'm sure you could contact the original author or, failing a response within 2 weeks or so from the current maintainer, you could put in a request on the AUR mailing list to have it orphaned so you can pick it up. It'd be worth reading the current rules on the wiki, though!
He who has no .plan has small finger.
~Confucius on UNIX.
Offline
I just uploaded this package: https://aur.archlinux.org/packages/dssi-vst-git/
Maybe it is of some use for you.
Offline
very nice, allready instaled and voted
Offline