You are not logged in.

#1 2018-07-23 14:28:31

epozzobon
Member
Registered: 2018-07-23
Posts: 2

Contributing can-isotp kernel module

Hi all,

I wrote a PKGBUILD script for the can-isotp kernel module (https://github.com/hartkopp/can-isotp) by copying the roccat-dkms package from AUR.

It seems to work ok and it is more convenient than building it from github because I don't need to reinstall it every time I update the kernel.

Now I would like to contribute the script to the AUR, but I have some questions about packaging it:

  1. In PKGBUILD, should I list the original developer as a Maintainer or as a Contributor?

  2. Should I name the package "can-isotp" like it is named in the original git repository, or "can-isotp-dkms" to me more consistent with other kernel modules built with dkms on the AUR?

  3. The original git repo does not use a version number or releases. Is it ok to use the date of the commit in this format: 2018.06.23?

  4. In PKGBUILD, should the 'url' variable point to the original repository of the software, or to the repository of the PKGBUILD script?

  5. Since I can not set the source archive to be the master branch zip from github, and using the whole git commit hash would be unreadable in every line it is used, is it ok to use a '_gitcommit' variable in the PKGBUILD?

My PKGBUILD is currently on github here: https://github.com/epozzobon/arch-can-isotp , any correction would be greatly appreciated.

Offline

#2 2018-07-23 14:58:43

loqs
Member
Registered: 2014-03-06
Posts: 17,195

Re: Contributing can-isotp kernel module

epozzobon wrote:

In PKGBUILD, should I list the original developer as a Maintainer or as a Contributor?

Unless upstream has contributed to the creation of the PKGBUILD itself do not list them as a contributor and you would be the package maintainer.

epozzobon wrote:

Should I name the package "can-isotp" like it is named in the original git repository, or "can-isotp-dkms" to me more consistent with other kernel modules built with dkms on the AUR?

I would choose the latter

epozzobon wrote:

The original git repo does not use a version number or releases. Is it ok to use the date of the commit in this format: 2018.06.23?

See https://wiki.archlinux.org/index.php/VC … 9_function "If there are no tags then use number of revisions since beginning of the history"

epozzobon wrote:

In PKGBUILD, should the 'url' variable point to the original repository of the software, or to the repository of the PKGBUILD script?

https://wiki.archlinux.org/index.php/PKGBUILD#url

epozzobon wrote:

Since I can not set the source archive to be the master branch zip from github, and using the whole git commit hash would be unreadable in every line it is used, is it ok to use a '_gitcommit' variable in the PKGBUILD?

Yes I would recomend you switch to using a pinned commit from the git repository rather than github's autogenerated archive.

conflicts=('can-isotp')
provides=('can-isotp')

A package always provides itself and conflicting with itself makes no sense.
can-isotp.install in not needed the pacman hooks for dkms will build the module on install and remove on removal.
Edit:
license should be GPL2 or GPL2/BSD and then include the COPYING file as per https://wiki.archlinux.org/index.php/PKGBUILD#license

Last edited by loqs (2018-07-23 15:19:28)

Offline

#3 2018-07-23 16:04:43

epozzobon
Member
Registered: 2018-07-23
Posts: 2

Re: Contributing can-isotp kernel module

loqs, thank you very much for the feedback, I'll correct it and submit it as soon as possible

Offline

Board footer

Powered by FluxBB