FS#17114 - [namcap] Doesn't properly detect custom license with -svn packages

Attached to Project: Arch Linux
Opened by Gavin Bisesi (Daenyth) - Thursday, 12 November 2009, 21:03 GMT
Last edited by Allan McRae (Allan) - Saturday, 06 February 2010, 02:11 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Hugo Doria (hdoria)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: namcap looks for $pkgname/ to hold the custom license, but for -svn packages (and others), that's not right.

Steps to reproduce:
$ namcap dwarftherapist-svn-296-1-i686.pkg.tar.gz
dwarftherapist-svn E: Missing custom license directory (usr/share/licenses/dwarftherapist-svn)

$ find pkg/ -name LICENSE
pkg/usr/share/licenses/dwarftherapist/LICENSE
This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 06 February 2010, 02:11 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Packaging policy is to use $pkgname
Comment by Allan McRae (Allan) - Thursday, 12 November 2009, 22:39 GMT
That seems a packaging bug to me. Licenses should be stored in $pkgdir/usr/share/license/$pkgname. Otherwise you would get conflicts if you have both the stable and (e.g.) git version of a package installed in parallel.
Comment by Gavin Bisesi (Daenyth) - Thursday, 12 November 2009, 22:52 GMT
Are there any packages where the stable and git versions do not conflict? In most cases, they conflict with each other, and in that case I think it makes more sense to have it under softwarename/ rather than pkgname/

Your thoughts? It's not a huge deal, but I think it's perhaps not correct.
Comment by Dan McGee (toofishes) - Saturday, 14 November 2009, 02:41 GMT
Our packaging policy at least is to have it at $pkgname, not $binaryname, so I'd tend to agree with Allan here.
Comment by Gavin Bisesi (Daenyth) - Saturday, 14 November 2009, 04:45 GMT
I suppose that's true, and for most things it makes sense. I disagree that it's correct for this, but it's a really minor issue, so if you think it would be better the other way, that's fine.

Loading...