Em 18/11/2013 09:27, G. Schlisio escreveu:

well spotted misspelling, but his question was to put license file into /usr/share/licenses/gnuplot{,-nox}. i suppose you could try adding a symlink from gnuplot-nox to gnuplot, so namcap complains no more. quite some other packages do that as well. georg

Well, Arch packaging standard says /usr/share/licenses/$pkgname is the correct license folder. And namcap respects that while verifying his package. Case it is not desire of the maintainer to use this standard (without typos and in $pkgname dirname), arch system won't break... but he will not be following correctly the aforementioned standard. ps.: Doing a symlink won't vanish namcap's warning because symlink != directory. Anyway, it is just a warning.

On Mon, Nov 18, 2013 at 12:23 PM, JoKoT3 wrote:

Thanks,

the typo is just in my mail, the PKGBUILD is correct (OT: according to wikipedia, "license" is used in american english but "licence" is used in all other english speaking countries. In french the word is also "licence"... my brain hurts).

I agree that it is more a philosophical question than a technical one, but it seems logical to me to reflect that the licence applies to the software "gnuplot" and not to the package "gnuplot-nox".

regarding your ps, doing the symlink the other way around should get namcap happy (?). @g.schilisio : do you have a PKGBUILD in mind that does a symlink ? I'm looking for the "right" way to do it.

On Mon, Nov 18, 2013 at 12:53 PM, Rafael Ferreira wrote:

...

Em 18/11/2013 09:27, G. Schlisio escreveu:

well spotted misspelling, but his question was to put license file

...

into /usr/share/licenses/gnuplot{,-nox}. i suppose you could try adding a symlink from gnuplot-nox to gnuplot, so namcap complains no more. quite some other packages do that as well. georg

Well, Arch packaging standard says /usr/share/licenses/$pkgname is the correct license folder. And namcap respects that while verifying his package. Case it is not desire of the maintainer to use this standard (without typos and in $pkgname dirname), arch system won't break... but he will not be following correctly the aforementioned standard.

ps.: Doing a symlink won't vanish namcap's warning because symlink != directory. Anyway, it is just a warning.

-- Jonathan Gibert Consultant www.iconsultants.fr

I'm also interested in the correct fix. This is a problem that affects every -git package. J. Leclanche

On Mon, Nov 18, 2013 at 12:57 PM, G. Schlisio wrote:

...

do you have a PKGBUILD in mind that does a symlink ? I'm looking for the "right" way to do it.

please refrain from top posting, as there is a bottom post policy here.

first package i encountered is extra/nvidia-utils [0] (PKGBUILD can be retrieved via abs [1]) there you find

install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/nvidia/LICENSE" ln -s nvidia "${pkgdir}/usr/share/licenses/nvidia-utils"

the same is done for a lot of lib32-packages in multilib. even if you still get a warning from namcap, this looks like a nice, clean and commonly accepted solution to me. georg

[0] https://www.archlinux.org/packages/extra/x86_64/nvidia-utils/ [1] https://wiki.archlinux.org/index.php/Abs

In that case, maybe it should be taken into account by namcap. And added to the packaging guidelines. :)

On 18/11/13 16:02, Nowaker wrote:

...

the same is done for a lot of lib32-packages in multilib. even if you still get a warning from namcap, this looks like a nice, clean and commonly accepted solution to me.

Both solutions look nice, clean and are commonly accepted. The important question is what the purpose behind /usr/share/licenses/$pkgname was. If the purpose was to know the license of a specific package, then it just wins.

I would assume another reason for the $pkgname part is to ensure no two packages that can be mutually installed could ever have a filesystem conflict on the license file (ensuring uniqueness by the fact no two packages/AUR PKGBUILDs can have the same name). In cases where you're both providing AND conflicting the non-git version, however, this point seems not to matter. -- Simon Hollingshead simon.hollingshead@gmail.com