On 16 June 2012 07:56, Kwpolska wrote:

On Sat, Jun 16, 2012 at 12:52 AM, Mateusz Loskot wrote:

...

I have created first version of proj-svn package for PROJ.4, a cartographic projections library hosted at http://proj.osgeo.org

I attached two files, PKGBUILD and ChangeLog. I'd like to ask for review and comments.

Do these files look OK? Can I pack these files into proj-svn.tar.gz and submit to AUR?

Not that way.  You should do `makepkg --source` in the directory with your PKGBUILD file.

Right, I missed that option.

And in terms of your PKGBUILD:  * set description to “Cartographic Projections library, SVN version.” so it is like the upstream package.

I'd like to include the PROJ.4 part in the description. IMO, it's important to avoid confusions. As mentioned, there are two or even three similar projects with proj or proj4 in name.

 * arch=('i686' 'x86_64')

Done.

 * remove empty entries.

Done.

 * ${srcdir}, ${pkgdir}

I'm not sure I understand. Should I remove all uses of these variables? I assumed they're set implicitly when user runs makepkg -s

 * you don't need the ChangeLog file,

I understand it's optional, but do you mean it's advised to not to include it? It doesn't hurt to have it, does it?

and you didn't show us any COPYING, but you install one.

COPYING file is grabbed with sources from SVN. Here it is http://svn.osgeo.org/metacrs/proj/trunk/proj/COPYING Should I include copy of this file in the package?

...

Note, there are a few related or similar packages available:

* proj - stable version of PROJ.4 https://www.archlinux.org/packages/?name=proj

* proj-old - old version of PROJ.4 https://aur.archlinux.org/packages.php?ID=59040

* libproj4 - is a different library to PROJ.4 https://aur.archlinux.org/packages.php?ID=21666 Homepage: http://home.comcast.net/~gevenden56/proj/ Historically, it is related to PROJ.4, names are similar, but they are distinct projects.

So, proj-svn is not a duplicate of any existing package.

No need to tell that.

It's a brief background to avoid potential answers like "Wait, but we have some PROJ.4 sutff already!" Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 16 June 2012 14:19, Kwpolska wrote:

On Sat, Jun 16, 2012 at 1:48 PM, Mateusz Loskot wrote:

...

On 16 June 2012 07:56, Kwpolska wrote:

...

 * ${srcdir}, ${pkgdir}

I'm not sure I understand. Should I remove all uses of these variables? I assumed they're set implicitly when user runs makepkg -s

Nope.  In your code, you use $srcdir.  When you should use ${srcdir}. See the difference?

Yes, I do understand the difference, but in your response it wasn't obvious what you are pointing at from. FYI, I copied PKGBUILD from /usr/share/pacman/PKGBUILD-svn.proto installed from https://projects.archlinux.org/abs.git/tree/prototypes/PKGBUILD-svn.proto?id...

...

...

and you didn't show us any COPYING, but you install one.

COPYING file is grabbed with sources from SVN. Here it is http://svn.osgeo.org/metacrs/proj/trunk/proj/COPYING Should I include copy of this file in the package?

Didn't actually check that in the source.  If your package does create a license file in /usr/share/licenses, the current method is okay.  If not, fix it.

Understood. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 16 June 2012 14:46, Andrew Gregory wrote:

...

...

...

 * ${srcdir}, ${pkgdir}

I'm not sure I understand. Should I remove all uses of these variables? I assumed they're set implicitly when user runs makepkg -s

Nope.  In your code, you use $srcdir.  When you should use ${srcdir}. See the difference?  The braces are important: if someone uses spaces in their build directory, your PKGBUILD will fail to work.

Braces have nothing to do with spaces in paths; they allow you to use variables followed by other characters that could be part of the variable name: ${foo}bar vs $foobar. You need to surround paths with quotes to protect against spaces: "$srcdir/foobar"

Thanks for clarification, I was a bit confused indeed. Now, with all the suggested changes applied, is the proj-svn package (created with makepkg --source) ready for submission to AUR? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

As the software is Licensed under MIT license you do not have to copy the COPYING file into the package. You only need to copy the COPYING file if you set license=('custom: foobar'), but if the license is one of the licenses included in [core]/licenses (is even in base group) package license=('license_name') is enought. (GPL1/2/3, MIT, APACHE....)

Am 16.06.2012 18:57, schrieb Kwpolska:

On Sat, Jun 16, 2012 at 5:32 PM, Jesse Juhani Jaara wrote:

...

As the software is Licensed under MIT license you do not have to copy the COPYING file into the package. You only need to copy the COPYING file if you set license=('custom: foobar'), but if the license is one of the licenses included in [core]/licenses (is even in base group) package license=('license_name') is enought. (GPL1/2/3, MIT, APACHE....)

The original package in repos DOES install a COPYING file. For a reason.

...

All source, data files and other contents of the PROJ.4 package are available under the following terms. Note that the PROJ 4.3 and earlier was "public domain" as is common with US government work, but apparently this is not a well defined legal term in many countries. I am placing everything under the following MIT style license because I believe it is effectively the same as public domain, allowing anyone to use the code as they wish, including making proprietary derivatives.

Though I have put my own name as copyright holder, I don't mean to imply I did the work. Essentially all work was done by Gerald Evenden.

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

Copyright (c) 2000, Frank Warmerdam

You need one with BSD and MIT. They (at least BSD does) force you to insert a copyright line. And so, every package under such licenses has a file in /usr/share/licenses.

I allways do a ls /usr/share/licenses/common/ which gives me AGPL Apache Artistic2.0 CDDL EPL FDL1.2 GPL GPL3 LGPL2.1 LPPL PerlArtistic PSF W3C AGPL3 APACHE CCPL CPL FDL FDL1.3 GPL2 LGPL LGPL3 MPL PHP RUBY ZPL if I am not sure about if a license is common in Arch's sense or not. As you see, MIT is not common. So the license file is needed in this case. Regards Stefan