Subject: [alpine-devel] Alpine ports layout

From: Cág <[email-masked]>
Date: Fri, 1 Sep 2017 20:36:28 +0100

Timo Teras wrote:

> New aports should start in 'testing'. We don't usually accept direct
> contributions to 'main' or 'community'. In most cases 'community' will
> be the right place for package, and I suspect this will be datamash's
> place when matured. Packages in 'main' are expected to have long
> maintained stable release branches.

I think that these conditions are vague. When should a testing port
become a community one and a community one become main?

How about splitting ports into categories, so gcc would be lang/gcc,
vim would be editors/vim and firefox would be www/firefox? Those that
aren't stable could land in wip, like in pkgsrc.

-- 
caóc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: William Pitcock <[email-masked]>
Date: Fri, 1 Sep 2017 19:10:31 -0500

Hi,

> become a community one and a community one become main?

The testing repository is really similar in spirit to pkgsrc's "wip" repository.
Packages leave testing when a developer decides to sponsor a changeset
that moves it to community or main (usually community).
In some cases, packages move from testing to main, but moving a
package to main implies that the core team has more authority over the
package, so usually packages that are from contributors stay in
community.
Another difference between community and main is that adding packages
to main is restricted to developers, while instead, community packages
can be maintained directly by maintainers (which have only a limited
subset of commit rights and no other rights that developers get).
We hope to make this, as well as the procedures for contributing
packages as a contributor, gaining maintainer rights, and becoming a
developer, in a developer's manual shortly.

> aren't stable could land in wip, like in pkgsrc.

This type of layout is very BSD/Gentoo-like.  Alpine is not either of
these things.

A better system would be to attach metadata to packages, which would
allow us to tag them.
So, a package could have in it's metadata:

   pkgname="firefox"
   scope="browser toolkit:gtk3"

Or similar.  Then we could use something like "apk search
--field=scope browser" to list the packages that are tagged as
browsers.

William

---

---

From: "A. Wilcox" <[email-masked]>
Date: Fri, 1 Sep 2017 14:57:26 -0500

On 01/09/17 14:36, Cág wrote:
> Timo Teras wrote:
> 
>> New aports should start in 'testing'. We don't usually accept
>> direct contributions to 'main' or 'community'. In most cases
>> 'community' will be the right place for package, and I suspect
>> this will be datamash's place when matured. Packages in 'main'
>> are expected to have long maintained stable release branches.
> 
> I think that these conditions are vague. When should a testing
> port become a community one and a community one become main?

There is no formal policy as of yet to handle when a package moves
from testing to community.  Usually it is after multiple people test
it and see that it is working.  Perhaps that will be defined better
after the docs are updated, which is a WIP.

> 
> How about splitting ports into categories, so gcc would be
> lang/gcc, vim would be editors/vim and firefox would be
> www/firefox? Those that aren't stable could land in wip, like in
> pkgsrc.
> 

Short version: packages fit in to multiple categories.  This wouldn't
make sense.

Long version: Speaking from experience having been involved with
multiple systems (Gentoo, FreeBSD, and NetBSD, to name a few), package
categories were always a pain point.  Some great examples:

Does OpenSSH belong in security/, net/, admin/, or something else?

Are we going to put every desktop/graphical package under "x11/"?  Or
is that just for X.Org and base libraries?  Do we add "gnome/",
"kde/", "lxqt/", and so on as categories?  Where do packages like
Pidgin go, which are strictly Gtk+ but have integration with both
Gnome and KDE?

Is "www/" for clients like Firefox?  Servers like Apache?  Both?
Would a user really want to scroll through a bunch of nginx modules to
see what browsers are available?

Also, packages are categorised the way they are to show the level of
support they have.  "main" is reserved for packages that have
upstreams committed to maintaining stability, as Timo stated.
"community" is for packages that may not be so stable.  This way you
know exactly what you are getting yourself in to (and can even disable
community repo if you really need stability guarantee).

A much better solution to package /discovery/, OTOH, would be to add
tags to the package metadata.  Free-form text field, as many as you
want, and we should have a list of ones that we use but allow users to
come up with their own for new types of packages that we may not have
even thought up yet.  "Web Browser", "Text Editor: CLI", "Text Editor:
GUI", etc.  I'm thinking something akin to PyPI, but haven't fleshed
out the details just yet.

Best,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org

---

---

From: Cág <[email-masked]>
Date: Fri, 1 Sep 2017 21:27:57 +0100

> 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.

> Pidgin go, which are strictly Gtk+ but have integration with both

x11/ is for window managers, icon themes, panels, common files for
desktop environments. So, for gnome-panel applets that monitor traffic
there's net/. Xfce's Thunar is in sys/. For Pidgin there's chat/.

> see what browsers are available?

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.

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
pkgsrc.se, I think the way the ports are organised is sane.

> community repo if you really need stability guarantee).

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.
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).

-- 
caóc

---

---

From: Jakub Jirutka <[email-masked]>
Date: Sat, 2 Sep 2017 13:09:39 +0200

> 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.

> doesn't search by descriptions.

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

> pkgsrc.se, I think the way the ports are organised is sane.

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

> 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.

> 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…)

Jakub

---

---

From: Shiz <[email-masked]>
Date: Sat, 2 Sep 2017 15:44:35 +0000

> On 2 Sep 2017, at 13:09, Jakub Jirutka <[email-masked]> wrote:
> 

I’d like to add to this that I think security is possibly the worst category
out of the given choices to put this in. OpenSSH’s purpose is not primarily
security — its primary purpose is administering a system remotely, security
is simply a bycoming necessity for that.

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

This is really not an argument on its own, as we take plenty of cues from BSD.
I like categorisation too but I’m not quite sure if it would fit for us, however.

> 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…)

For the record, I have, and also from Gentoo’s packaging system which takes cues
from BSD as well.

- Shiz

---

From: Jakub Jirutka <[email-masked]>
Date: Sat, 2 Sep 2017 18:06:14 +0200

> is simply a bycoming necessity for that.
This just demonstrates weakness of categories. Categories (usually defined as: object may be in a single category only, categories are a predefined and narrow set of names) are almost always worse idea and does not really suite real world. Tags (usually defined as: object may have multiple tags, tags are an open set of names) are almost always better. It’s very obvious in this case, so I hope it’s not needed to prove it by studies…

> I like categorisation too but I’m not quite sure if it would fit for us, however.

Yes, but still arguments in style “BSD has this, so we should too” should be invalid.

> For the record, I have, and also from Gentoo’s packaging system which takes cues

Gentoo packaging system is very different from package manager that does not even properly handle dependencies, big pile of Makefiles, basically absence of sane update mechanism for ports… Anyway, this is irrelevant.

The main point is that adding categories (like in Gentoo or BSD) to improve discoverability of packages is provably very, very bad and insufficient solution and we know about much better solutions.

Jakub

---

---

From: Jakub Jirutka <[email-masked]>
Date: Fri, 1 Sep 2017 22:07:07 +0200

> How about splitting ports into categories, so gcc would be lang/gcc, vim would be editors/vim and firefox would be www/firefox?

1. This is orthogonal to main vs. community, i.e. it has totally different meaning.
2. I know this layout very well from Gentoo. It looked like a good thing at the beginning, but eventually I found out that it’s really not. There’s no clear (unambiguous) exclusive relation between packages and limited set of categories, it’s very common that one package may fit into multiple categories or none.

Jakub

> On 1. Sep 2017, at 21:36, Cág <[email-masked]> wrote:
> 
> Timo Teras wrote:
> 

---