Creating a new package essentially comes down to writing an rpm spec file for it, uploading the source, putting the spec and source into a git repository, and building it on abf.
A spec file is essentially a collection of metadata and a shell script to build the package - it can also use macros and other shortcuts to make the script shorter.
The best way to get started with a spec file is usually to use the tools included in the packaging-tools package. Install it with dnf install packaging-tools, then read the man pages for vs, vl, and vp.
The idea is to let the v* tools generate a template that you just have to fill out. Usually that template is good enough to work with only minor tweaks.
If you want to know more details about spec files, read the the RPM packaging guide at https://rpm-packaging-guide.github.io/ - this guide is a little Fedora centric, but the spec files are very similar.
When you have a spec file you would like to try, run abb build to see if it compiles.
If everything is fine, you can submit the source files to the file server using abb store FILENAME or abf put, then commit the spec file, .abf.yml (this file is generated by abb/abf) and any patches you may have applied to a git repository.
If you have sufficient access already, you can just use addpkg to:
In general, the spec files are similar with a few minor differences - we don't add %{?dist} to the Release: field, and we don't use/mandate the %changelog section (the way to get changelog information in OpenMandriva is to use git log on the repository containing the spec).
But there are a few additions in OpenMandriva that can make your life as a package maintainer a lot easier:
If something uses a standard build system, you can avoid using all the boilerplate to invoke build system commands. If a traditional spec file says, for example
%prep
%autosetup -p1
%conf
%configure --enable-feature --disable-other-feature
%build
%make_build
%install
%make_install
You can remove all that and just put
BuildSystem: autotools
BuildOption: --enable-feature
BuildOption: --disable-other-feature
Similarily, if a spec file says something along the lines of
%prep
%autosetup -p1
%conf
%cmake -DFEATURE_XYZ:BOOL=ON
%build
%make_build -C build
%install
%make_install -C build
You can just put
BuildSystem: cmake
BuildOption: -DFEATURE_XYZ:BOOL=ON
The same goes for meson and python (using setup.py or pip wheel to build the package).
The basic idea for updating to a newer version is to download the existing packaging data, bump the Version: field, and build it. With any luck, this will already be sufficient to update a package.
Of course, sometimes you have to adjust the file list, add new options, rebase patches, or simply fix up an old spec file that uses features that have been removed from the current version of rpm.
There is a script that can help check for updates: https://github.com/OpenMandrivaSoftware/packaging-tools/blob/master/auto-update - download it using git clone https://github.com/OpenMandrivaSoftware/packaging-tools.
If you invoke it just as ./auto-update, it will go over all packages in the repository, check if it can detect a newer version, and if so, try to automatically update. (This will fail if the update requires more effort than just bumping the Version: field. Such failed builds will be moved to ~/failed-builds so you can investigate and fix them.)
It is usually not recommended to run auto-update on the entire repository unless you're a core maintainer knowing when to do it.
If you want to update a specific package, use ./auto-update PACKAGENAME. This downloads the source for PACKAGENAME, tries to bump the version, and on success upload the changes to the repositories and trigger a new build in abf (assuming you have sufficient permissions for each of those steps already). On failure, the attempted but failed update is moved to ~/failed-builds, so you can cd ~/failed-builds/PACKAGENAME, look at the build log, fix the spec, and run abb build again to check if it works now.