Mail archive

Re: [alpine-devel] Alpine ports layout

From: Jakub Jirutka <>
Date: Sat, 2 Sep 2017 13:09:39 +0200

On 1. Sep 2017, at 22:27, Cág <> wrote:

>> Does OpenSSH belong in security/, net/, admin/, or something else?
> security. net/ is for dhcpcd/openvpn/vnc kind of stuff. admin/ doesn't
> even exist in Net/OpenBSDs.

Why? This is just arbitrary decision, it’s not obvious nor intuitive. On Gentoo, I usually remember package name, but not the category, so I must always look in what damn category the package is located.

> For both. Now there's no way anyway to see what browsers are available:
> Firefox is in testing, -esr is in community; Chromium is in community
> and netsurf is in testing while lynx is in main. apk, as far as I know,
> doesn't search by descriptions.

This can be simply solved by adding tags into APKBUILDs and APKINDEX.

> Anyway, if there would be a heated discussion on where a port whould be
> placed, we can look at BSDs and simply copy. Take a quick glance at
>, I think the way the ports are organised is sane.

Alpine Linux is not BSD. If you want BSD’s repository layout, use BSD.

> That's what I'm talking about - it's vague. It should be either stable
> or not stable, so it would land in wip/. And wip/ is a different repo.

Yes, it’s currently vague. We should define it better and reorganize the packages. The community repository is not here from the beginning, so there are plenty of packages in main that should be actually in the community.

It’s not stable vs. not stable, main and community has different support. Packages in the main repository should be supported (security fixes) at least for 2 years, packages in community for at least 6 months. That’s also the reason why we have main/nodejs (LTS) and community/nodejs-current (current). The further is supported by upstream for less than 2 years, so we can’t guarantee 2 years support.

> On NetBSD wip packages are only in the tree and not in repos (because most
> of them can’t be compiled, but that's another story).

Why to clutter repository with abuilds that can’t be even built? That’s non-sense and anti-pattern. Aport is merged into the repository after it passed build and code-review, until then is in separate branch in the contributor’s repository that is visible for us as a pull request (or patch in Patchwork). This is standard systematic approach that works.

The first stage for new aports is the testing repository. Testing doesn’t mean that the packages there may be totally broken and cannot be even built, but they may not be completely finished. The intent is to provide such package to wider audience and move it into community or main after some feedback that it really works.

Again, Alpine is not BSD and it’d be quite silly to blindly adopt practices from BSD, especially in packaging (I’ve never heard anything positive about packaging on BSD even from BSD users…)


Received on Sat Sep 02 2017 - 13:09:39 UTC