You are not logged in.
I want to create a package for Triangle (http://www.cs.cmu.edu/~quake/triangle.html).
My current pkgbuild looks like:
pkgname=triangle
pkgver=1
pkgrel=1
pkgdesc="A Two-Dimensional Quality Mesh Generator and Delaunay Triangulator."
arch=('i686' 'x86_64')
url="http://www.cs.cmu.edu/~quake/triangle.html"
license=('custom')
provides=('triangle' 'showme')
conflicts=('triangle' 'showme')
source=(http://www.netlib.org/voronoi/triangle.zip)
md5sums=('10aff8d7950f5e0e2fb6dd2e340be2c9')
build() {
cd "$srcdir"
gcc -O -o triangle triangle.c -lm
gcc -O -o showme showme.c -lX11
}
Now, I don't know what to do from here... all the help on the wiki assumes make, make install; whereas this isn't the case here. I think I need to copy the resulting executable to /usr/bin, but I'm not sure at all.
Any help would be much appreciated.
Offline
Adding
install -Dm755 triangle "$pkgdir/usr/bin/triangle"
install -Dm755 showme "$pkgdir/usr/bin/showme"
to the build() function works for me.
edit: this was probably the wrong place to post this, should have posted it to "PKGBUILDs & ABS Support".
Last edited by anitsua (2010-08-18 02:49:38)
Offline
Adding
install -Dm755 triangle "$pkgdir/usr/bin/triangle" install -Dm755 showme "$pkgdir/usr/bin/showme"
to the build() function works for me.
To be technically correct, those lines should be added to a package() function
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
anitsua wrote:Adding
install -Dm755 triangle "$pkgdir/usr/bin/triangle" install -Dm755 showme "$pkgdir/usr/bin/showme"
to the build() function works for me.
To be technically correct, those lines should be added to a package() function
Shouldn't this function be described in the Creating Packages wiki? There is a "The build() function" chapter but none about the package() function except of it being listed in the example.
I did miss this function up to now as well.
BTW: The package() function is missing in the "PKGBUILD Prototype" chapter of the Arch Packaging Standards wiki as well. Is this a new concept?
Last edited by bernarcher (2010-08-18 07:50:13)
To know or not to know ...
... the questions remain forever.
Offline
Shouldn't this function be described in the Creating Packages wiki? There is a "The build() function" chapter but none about the package() function except of it being listed in the example.
I did miss this function up to now as well.
BTW: The package() function is missing in the "PKGBUILD Prototype" chapter of the Arch Packaging Standards wiki as well. Is this a new concept?
Technically, you don't have to put anything in the package() function; using build() is enough. Still, it's not the "Arch Way" of doing things. You are right though, it should be documented in the wiki.
It is better to keep your mouth shut and be thought a fool than to open it and remove all doubt. (Mark Twain)
Offline
anitsua - triangle is already in the AUR. Always check there first before packaging anything.
bernarcher - the package() function is detailed in the official documentation provided by the pacman developers i.e. the PKGBUILD man page. The wiki is not official, as it is maintained by the Arch community, and in this case nobody has updated the related wiki pages yet.
Offline
@tomk
Sure. But the wiki is (should be) the first information source for mere beginners (as I was with my first PKBUILD attempts). Thus some more complete (tutorial!) information would be appreciated.
The PACKAGE() section of the man isn't very helpful, btw:
PACKAGE() FUNCTION
An optional package() function can be specified in addition to the
build() function. This function is run immediately after the build()
function. When specified in combination with the fakeroot BUILDENV
option in makepkg.conf(5), fakeroot usage will be limited to running
the packaging stage. An existing build() function will be run as the
user calling makepkg.
This merely states that it is optional and run immediately after the build() section. But no mentions about putting install commands into this section -- at least this one (and preferably why to do so) belongs in the wiki, imo.
To know or not to know ...
... the questions remain forever.
Offline
anitsua - triangle is already in the AUR. Always check there first before packaging anything.
Yes. I know it is, because I put it there just after I got it to work correctly
Offline
anitsua - lol , I should have checked the date...
bernarcher - I disagree. The first resource that any user should avail of is the official resource. The Arch wiki has a deservedly excellent reputation, but it is not the holy grail, and it is NOT official.
If you feel the man page could be improved, submit a feature request, or even better, a patch.
Offline
Of course the wiki is not official. And of course as well I advice anybody to consult man pages and other official documentation.
But - because we do have those really splendid wiki articles - it is usual practise to rely first hand on the information provided there. I do not speak against using official doumentation. But why not try to keep the wiki as up to date as possible? In this case I cannot do it myself - just not knowing enough about this topic - but it should be no severe task for a gifted developer, should it?
A feature request for the man page is a good idea. I only just now stumbled over this theme (and did not even think about this request possibility ). But I will proably file some the next days.
Nevertheless, no need for flaming. I only wanted to hint where we could grow even better.
Last edited by bernarcher (2010-08-18 10:43:56)
To know or not to know ...
... the questions remain forever.
Offline
For your sake, I hope you are not describing my comments here as flaming - it is not a good thing to be that sensitive.
All wiki users are expected to use their own judgment when consulting the wiki. Blindly relying on information provided there is not a good idea, and you should not assume that everyone does so, just because you do.
You don't need to be a "gifted developer" to update the wiki - anyone who understands the basic information can do it. If you don't feel you have the necessary understanding, that's fine - all you need to do is wait patiently until someone else does it.
Offline
Shouldn't this function be described in the Creating Packages wiki? There is a "The build() function" chapter but none about the package() function except of it being listed in the example.
I didn't know it was missing from the wiki -- it it only about 6 months (?) old now.
Technically, you don't have to put anything in the package() function; using build() is enough.
Hence I said "should" instead of "must". I'm an RFC
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
For your sake, I hope you are not describing my comments here as flaming - it is not a good thing to be that sensitive.
Oh my god, by no means, no... *** \me blushing ***
I apologize for that. Never meant to be rude.
To know or not to know ...
... the questions remain forever.
Offline
credit : here I reformulate the explanation I got from JGC on IRC.
The package() is the step where makepkg construct the package. If no package() function is found (like in old packages) makepkg assumes build() will do everything.
The main difference between a package that has only a build() function and one that also has package() is that build() is run without fakeroot in the latter case. For most packages it doesn't matter which option you take, but having only a build() function can cause problem to some packages (for example when the build process try to write in the home directory, which is /root with fakeroot).
Offline
It also has the benefit of being able to run makepkg -R to only rerun the package() part of the PKGBUILD if you've only made changes to that after previously running the whole makepkg process. This can save a lot of time on compilation intensive PKGBUILD's, and/or slower computers.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline