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 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.) -- Eli Schwartz Bug Wrangler and Trusted User