I asked about this a couple of days ago, but looking once again at the documentation and reading the sticky post "To all AUR Users / Submitters" made by phrakture in the Announcements section, I got confused. I think there may be some conflicting information in the documentation on what exactly to submit to the AUR. To clarify a few points and make sure I do things right in the future, here is a concrete example...
Looking at many of the submissions to the AUR, it seems as though most people create a file named foo.tar.gz which contains only these things:
foo/ foo/PKGBUILD and whatever .install/patch files are necessary
Supporting this are the instructions found on the AUR Guidelines page, which states:
Inside the web interface, a user can submit a tarball (tar.gz) of a directory containing build files for a package. The directory inside the tarball should contain a PKGBUILD, any .install files, patches, etc (no binaries). Examples of what a directory looks like can be seen inside /var/abs.
This approach is what is most commonly found in the AUR, and what I ended up doing for the package I made...however, the Arch Linux Installation Guide states:
All packages should come as a compressed tar file containing a directory with the newly built package, the PKGBUILD, filelist, and additional files (patches, install, ...) in it. The archive name should at least contain the name of the package.
Which would lead me to believe a submission to the AUR would be a file named foo.tar.gz containing:
foo/ foo/PKGBUILD foo/filelist foo/foo-1.0-1.pkg.tar.gz and whatever .install/patch files are necessary
Hopefully someone can clarify this for me...
tar up the directory structure that you would expect to find in abs *before* compiling a package.
foo/PKGBUILD foo/foo.install foo/foo_bar.diff foo/foo.rc.conf foo/why_cactus_rocks.txt
tar the foo directory
tar -czvf foo.tar.gz ./foo
That section of the installation guide is quite dated, and does not pertain to the aur. it was in reference to the precursor to the aur (the TUR..which is no more).
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
What you read in the Arch Linux Installation Guide is in regards to the old ftp /incoming directory. Like it says at the end of that section of the document, "a new implementation of the whole procedure is currently being discussed among the developers" ... AUR.
of course, it should be updated. it actually has been updated a bit: it used to say to upload the file by ftp to incoming, which is obviously no longer done. they removed that part so that people won't do it anymore -- which has led to confusion, since it's assumed those are AUR instructions, and they're not.
i'm sure this will be brought to the attention of the lead documentor, and all will be fixed
Just to clarify - i think everyone is clear on the NO BINARY bit but also AUR pkgs DO NOT need to include the filelist
Elasti - I have updated the "new" guidelines as you suggested - thanks
that looks great dibble,
if my TU application get accepted i know where to look for getting started,
arch + gentoo + initng + python = enlisy
They're looking much better Dibble...one thing that I noticed is that you're missing the 'i' on the very last line of the AUR User Guidelines for the Using Packages in Unsupported. It should be makepkg -i or makepkg -ci, correct?
Also, I know this is just a test wiki, but I think that the background color change should be a little more dramatic for commands that you're supposed to enter on the CLI. The light grey is hard to differentiate on the white background. Even a darker grey would be nice.
favourite -> favorite ?
elasticdog: favourite, colour, mum,
Yarrrr...I know they're optional, but I thought it was confusing since you have "makepkg -" with nothing after it.
Double-YARRR, looking at it again, the dash isn't part of the command, but it looked like it since the grey background is so light...which brings me back to my other point