Hey guys.
I'm planning on packaging the linux kernel with OpenChrome DRM support from https://cgit.freedesktop.org/openchrome/drm-openchrome/ to share in the AUR.
What should I name the package?
1. linux-drm-openchrome-git 2. linux-drm-openchrome-next-git
And what should the description be? Something like "The Linux-drm-openchrome-git kernel and modules" ?
Thanks for your input.
Marc
I wonder if the following is acceptable:
pkgname = linux-drm-openchrome-git pkgdesc = The Linux kernel and modules from the drm-openchrome tree - git version
On Sat, Jun 15, 2019 at 11:50 PM Marc Ranolfi marc.2377@gmail.com wrote:
Hey guys.
I'm planning on packaging the linux kernel with OpenChrome DRM support from https://cgit.freedesktop.org/openchrome/drm-openchrome/ to share in the AUR.
What should I name the package?
- linux-drm-openchrome-git
- linux-drm-openchrome-next-git
And what should the description be? Something like "The Linux-drm-openchrome-git kernel and modules" ?
Thanks for your input.
Marc
On 06/15/2019 09:53 PM, Marc Ranolfi via arch-general wrote:
I wonder if the following is acceptable:
pkgname = linux-drm-openchrome-git pkgdesc = The Linux kernel and modules from the drm-openchrome tree - git version
That seems to meet all normal naming conventions and the description is fine.
Thank you David.
If I may ask a related question - considering this package would be most useful for Arch Linux 32, how should I provide support for both x86_64 and i686?
The kernel packages I've seen in the AUR only support x86_64.
Should I make two separate packages - i.e. one like "i686- linux-drm-openchrome-git"?
I think it's also possible to have only one package (and two config files 'config.i686' and 'config.x86_64'). But I don't know if that is good practice.
On Sun, Jun 16, 2019 at 2:49 AM David C. Rankin < drankinatty@suddenlinkmail.com> wrote:
On 06/15/2019 09:53 PM, Marc Ranolfi via arch-general wrote:
I wonder if the following is acceptable:
pkgname = linux-drm-openchrome-git pkgdesc = The Linux kernel and modules from the drm-openchrome tree - git version
That seems to meet all normal naming conventions and the description is fine.
-- David C. Rankin, J.D.,P.E.
On 16/06/2019 21:12, Marc Ranolfi via arch-general wrote:
I think it's also possible to have only one package (and two config files 'config.i686' and 'config.x86_64'). But I don't know if that is good practice.
This is definitely possible and the approach Manjaro currently uses for `arch=(i686 x86_64)` kernels. I think it's based on the same approach as Arch kernels prior to the drop of i686 support.
Personally I'd prefer that approach over architecture-specific packages (and which is kind of the point of the `arch` array).
As to whether it's current good practice; I'll defer to an Arch dev for that.
J
On 6/16/19 4:21 PM, Jonathon Fernyhough wrote:
On 16/06/2019 21:12, Marc Ranolfi via arch-general wrote:
I think it's also possible to have only one package (and two config files 'config.i686' and 'config.x86_64'). But I don't know if that is good practice.
This is definitely possible and the approach Manjaro currently uses for `arch=(i686 x86_64)` kernels. I think it's based on the same approach as Arch kernels prior to the drop of i686 support.
Personally I'd prefer that approach over architecture-specific packages (and which is kind of the point of the `arch` array).
Yes, please. It only makes sense to use the same package name for both, and all kernels in the official repos and the AUR used this exact config.i686 scheme up until the official deprecation of i686 from Arch Linux. Some packages in the AUR still use it.
As to whether it's current good practice; I'll defer to an Arch dev for that.
It's more than good practice -- it is the rules. In order to submit a package to the AUR, it *must* be useful to Arch Linux. It is the Arch User Repository, not the Alarm User Repository (ALARMUR?) or Arch Linux 32 User Repository (I give up). If a package is completely useless on x86_64 and contains an arch=() that excludes x86_64, then I will delete that package unless someone else beats me to it. See https://wiki.archlinux.org/index.php/PKGBUILD#arch
That being said, we encourage users who wish to support alternative architectures to list all arches they support in their PKGBUILDs. For someone who principally uses i686, this is a no-brainer. :p
(Also: reminder that even though Arch usually has a bit of a rocky relationship with derivative distros, we are on exceedingly friendly terms with cpu ports like alarm and arch32.)
arch-general@lists.archlinux.org