New package submission request for help

doctorwhen · 2022-08-29 16:17:47

Hi, I'm a new Arch user. I'm a developer with many projects, many of which are packaged in Debian and RPM formats. I've recently packaged one of my projects, MusicPlayerPlus, with PKGBUILD for Arch Linux installation. I've submitted this package for inclusion in AUR - https://aur.archlinux.org/packages/musicplayerplus.

I'm posting here hoping to get some guidance/pointers wrt AUR package submission, testing, packaging, maintenance, and community involvement. Any direction would be greatly appreciated.

What are the next steps after making a package submission? How do I add keywords to my package to make it easier to find? How do I go about soliciting testing and feedback from other users? How can I improve the package for inclusion in AUR and improve the user experience when installing and using this package?

I've learned a lot in the last few weeks playing with Arch Linux, makepkg, PKGBUILD, pacman, and the AUR. And I've discovered I have a lot more to learn. I plan on packaging several other projects with PKGBUILD and submitting for inclusion in AUR. I'd like to do so in a manner that conforms with guidelines, expectations, and a pleasant user experience. Any help/info/suggestions/pointers/criticism welcome!

Scimmia · 2022-08-29 16:31:11

OK, first thing, Contributor/Maintainer tags refer to the PKGBUILD, not the upstream project.
The pkgrel is for package changes, it shouldn't be something that comes from upstream.
Why are you overriding all of the user's options in the options array?
post_install isn't meant to re-create the readme.
There's a WHOLE lot more simplification, but I'll have to look at that later unless someone else does it.

For keywords, you do that right on the page you linked to.

doctorwhen · 2022-08-29 17:29:49

Thanks Scimmia, that is exactly the kind of help I am looking for. I have updated keywords and I am simplifying the PKGBUILD and post_install following your guidelines.

I use the pkgver and pkgrel later in the PKGBUILD for specifying the tag to use to retrieve this version's source from github. If I change the pkgver to something like "v2.0.1r2" then I can just use pkgver for the tag and pkgrel for package changes as you suggest. Does that sound like the right way to proceed? Maybe use a pkgver() function to pull the version from the VERSION file in my upstream project somehow?

If I change the pkgver string then I reset the pkgrel to 1?

I set the options array so I could control some of the actions during makepkg. I will look into simplifying or removing this. Is it unusual to specify options? I can probably remove it.

Thanks for your prompt and helpful response.

Lone_Wolf · 2022-08-30 12:38:57

When using git to retrieve sourcecode at a specific point the custom on archlinux is to use a commit hash.
This ensures the user who builds the package will use the exact same version as the maintainer.

Upstream in general tends to change tags without notification. Building a specific commit also helps with troubleshooting.

While technically you could use a pkgver() function for a static value, usually that is only done for VCS-packages..
Also maintainers are supposed to test PKGBUILDS before submitting updates.
Manually changing versions fits that very well.

If I change the pkgver string then I reset the pkgrel to 1?

yes, that's the way it works.

    arch=`uname -m`
    [ "${arch}" == "armv7l" ] && {

No need to check uname.

https://wiki.archlinux.org/title/PKGBUILD#arch wrote:

The target architecture can be accessed with the variable $CARCH during a build.

Are you sure removing sse2 manaully is needed ?
I do expect archlinux-arm to set different CXXFLAGS in /etc/makepkg.conf then on x86_64 .

      have_cargo=`type -p cargo`
      if [ "${have_cargo}" ]
      then
        cd ${PROJ}
        PKGPATH=`pkg-config --variable pc_path pkg-config`
        [ -d /usr/lib/ffmpeg4.4/pkgconfig ] && {
          PKGPATH="/usr/lib/ffmpeg4.4/pkgconfig:${PKGPATH}"
        }
        export PKG_CONFIG_PATH="${PKGPATH}:/usr/lib/pkgconfig"
        cargo build --frozen --release --all-features
        cd ..
      else
        echo "The cargo tool cannot be located."
        echo "Cargo is required to build bliss-analyze."
      fi

You have listed cargo as a makedepend.
makepkg will notice very early if is not present and abort (or install it if automatically if -s, --syncdeps is added to its invocation).

your package() function does a lot of copying to destdir .
Most software instructs the build system where to put things and makes it accessible through an 'install' target .

doctorwhen · 2022-08-30 16:52:06

Thanks Lone_Wolf, I will revise the PKGBUILD and address most of the issues you raise. Not sure about the source retrieval by commit versus tag. I am the maintainer of this upstream repository and enforce release tag conformance with a strict format (vVERSIONrRELEASE). I am just learning PKGBUILD and there appear to be sophisticated techniques for retrieving info from git. I will study these and see if using a commit works well.

SSE2 is not supported on ARM. I will use $CARCH rather than uname. Or, perhaps a better check would be something like 'cat /proc/cpuinfo | grep sse2'.

I can remove the check for cargo as you suggest since it is a dependency.

Yes, the copying in package() is a mess. Creating a 'make install destdir=...' or something like that would be preferable. It's on my todo list.

Thanks for helping me everybody.

Arch Linux

#1 2022-08-29 16:17:47

New package submission request for help

#2 2022-08-29 16:31:11

Re: New package submission request for help

#3 2022-08-29 17:29:49

Re: New package submission request for help

#4 2022-08-30 12:38:57

Re: New package submission request for help

#5 2022-08-30 16:52:06

Re: New package submission request for help

Board footer