Add Arch Linux generator #409
Conversation
|
I don't have a strong feeling about starting at As to the release repository URL... that's a tough one. The problem is that the release repository could move or you could do the release on a git repository on your local filesystem and only after push it to a hosted repository. It would be better to somehow pass this information into the |
|
Apparently it's actually standard to start with a debian version number of
As well as Fedora: https://fedoraproject.org/wiki/Packaging:Versioning So we can make it consistent and use |
|
+1 for starting the release part at 1 instead of 0. |
|
If the release number is starting at 1 globally then I don’t need to add 1 to the Arch release number. For the release repository URL, I was guessing that it would break some workflows. I hesitated enabling it with a switch but that’s quite messy. The current proposal doesn't fit Arch convention but still works and is safe. Current generated Arch looks like that: Calling bloom-generator on a non-GIT folder for Arch won’t produce a valid package because files would be in the wrong location. Is it actually used? |
Per discussion in #409 This is what most distributions default to and expect.
|
I am performing some evening necromancy 💀 and opened pull request #528 to start release increments at 1 rather than 0 🦇. |
|
@nuclearsandwich . Thanks :-) . I started adding some support for Arch in the buildfarm (https://github.com/gdlg/ros_buildfarm) 2 years ago but haven’t had time to finish it. One problem that I encountered is that the release number is typically incremented in Arch everytime that an upstream package has a breaking ABI change. This actually happens quite often (e.g. Boost libraries) that it wouldn’t be realistic to ask all ROS maintainers to increment the release in their package every time this happen. Instead I have been thinking of moving the ROS release number inside the Arch version number and keep the Arch release number under the control of the buildfarm. If we use this method then we don’t need the ROS release to start at 1 anymore since it becomes independent from the Arch release number. I still think that #528 makes sense to match most distributions default but in retrospect, it is not needed for Arch. |
Do you have documentation describing this practice? My understanding of the pkgrel field is that it's used to allow iteration of the PKGBUILD for the same upstream version (same as it's used in Debian-derived distros). |
|
Not sure where the practice is documented. However here is an example: When a dependency is updated, the package need to be rebuilt. pkgrel is also incremented otherwise pacman wouldn’t detect that the package has been rebuilt. Besides Arch almost never provides multiple versions of the same library. Debian doesn’t have this issue because they rarely bump libraries to newer versions during the lifetime of a release and when they do, they provide multiple versions of libraries to keep older packages working (https://www.debian.org/doc/debian-policy/ch-sharedlibs.html). |
|
Okay, I see what you mean, Archlinux uses the pkgrel to trigger builds downstream of a dependency. The ROS buildfarm adds the build date to the version string for debian packages to do essentially the same thing. If you resume the Archlinux work and haven't seen that yet it'd be worth looking into. Since the pkgrel is usually a scalar integer but can be more, maybe you could use |
* Start release increment at 1. Per discussion in #409 This is what most distributions default to and expect.
|
Good idea. I’ll try |
5 participants
This changeset proposes changes to add an Arch Linux generator to Bloom.
The code was originally copied from the RPM generator and modified for Arch.
So far, to test it, I forked rosdistro (https://github.com/gdlg-rosarch/rosdistro) and the *-release repositories into https://github.com/gdlg-rosarch. I generated a new “rosarch” track for Arch which essentially duplicates the “kinetic” track and uses the last released version.
A few packages have missing dependencies but I successfully built and installed all the packages required by ros-kinetic-desktop-full.
A few issues:
Release number
The release number by convention starts at 1 on Arch but Bloom starts at 0.
To fix this issue, I incremented the release number by 1 in both the Arch package and the associated Git tag. Alternatively we could use 1 by default in Bloom.
Sources
Arch packages are normally constituted of a single PKGBUILD file and eventual patches/installation scripts in the top level directory. Sources are usually specified using URLs to remote archives/repositories.
The Debian or RPM method where source files are in the top level directory and packaging files in a subdirectory such as 'debian' or 'rpm' doesn't work with Arch. This changeset circumvents the problem by moving all the source files into a subdirectory. This is not the most elegant solution however I can’t think of any drawbacks.
A cleaner solution (from Arch point of view) would be to reference the sources URL in the PKGBUILD file; for instance we could use the URL of the -release repository on Github. However this URL is not readily available in git-bloom-release. We could potentially add the URL to tracks.yaml.