For discussion of Alpine Linux development and developer support

7 5

[alpine-devel] Alpine ports layout

Cág
Details
Message ID
<20170901193628.GB31533@alpine.my.domain>
Sender timestamp
1504294588
DKIM signature
missing
Download raw message
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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<59A9BBA6.1080805@adelielinux.org>
In-Reply-To
<20170901193628.GB31533@alpine.my.domain> (view parent)
Sender timestamp
1504295846
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZqbujAAoJEMspy1GSK50UkCAQAJYj8Gl2ic/my/jt0Gg8ExZS
X5JqVwf0EdOSxYXgWW7y3E3uTFGmXE9Zx5VCfbTpngHQgMciNDMZX+5JksHaupaa
s66AlYzfswOZyKc/eYITGFEy+8vRrLwEzo+sSK4Vc8Ayj98nwS/xvABkk5ULgmIu
/MnFybktRGGqMoG5psF64fzPZEq3MPe0wrpSEgQiIrruUthywQPm1CcJrtMMNS9I
Zvs9ftnQbTruhC7YJFP2Qwo5FhDcJQK6s2NV2imNn5y9Rj4SlfQeSI2SUx/iJUyQ
ihnkN5BAK59Pfbyo51pafLoiTLGeGtSfwfTAbWerlsif2BavY0boOWUaqq+O6w+F
7absnF3Yptb4VmaI8pCu1xVHFZrWVhxAj4Fz110ChezyEtzMCmvVvDaibL3It1C4
szhRctIAExub0420rEYekXfD+HszYc43QMwx8SLLvuXJrrX9mWSEcKtlhicsfwh1
JUkLp6VrGRdQPllCOL+gsZkYvILKKerZmATeb8O7EBUnLunO0cOE8QMvgHSE9A70
xUjLegiDd9CbBmJtrJ+7ZdzQknCStRHSflmcMGNNfBEwD54nTiXFxaC3KarpvPug
CRyPHswH3TOE/oEiRyRRS+XqMR6er74sUNfPzmmDJdf6DFNw44m5GcvOlw9pEuSw
3gCQwx4tb9QO0cd3A6Qy
=P/kZ
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCEibyTTECMMyM96-3RWrXFctE0gun69nWXNDfaLCzHYGA@mail.gmail.com>
In-Reply-To
<20170901193628.GB31533@alpine.my.domain> (view parent)
Sender timestamp
1504311031
DKIM signature
missing
Download raw message
Hi,

On Fri, Sep 1, 2017 at 2:36 PM, Cág <ca6c@bitmessage.ch> 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?

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.

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

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Cág
Details
Message ID
<20170901202757.GA9914@alpine.my.domain>
In-Reply-To
<59A9BBA6.1080805@adelielinux.org> (view parent)
Sender timestamp
1504297677
DKIM signature
missing
Download raw message
A. Wilcox wrote:

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

security. net/ is for dhcpcd/openvpn/vnc kind of stuff. admin/ doesn't
even exist in Net/OpenBSDs.

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

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

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

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.

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

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



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jakub Jirutka
Details
Message ID
<AD57503D-F1B5-4A73-95E6-7A29F47254DF@jirutka.cz>
In-Reply-To
<20170901193628.GB31533@alpine.my.domain> (view parent)
Sender timestamp
1504296427
DKIM signature
missing
Download raw message
> 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

> I think that these conditions are vague. When should a testing port
> become a community one and a community one become main?
> On 1. Sep 2017, at 21:36, Cág <ca6c@bitmessage.ch> 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?
> 
> 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:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jakub Jirutka
Details
Message ID
<3B3AC404-2958-4FF1-B54A-586130A89222@jirutka.cz>
In-Reply-To
<20170901202757.GA9914@alpine.my.domain> (view parent)
Sender timestamp
1504350579
DKIM signature
missing
Download raw message
On 1. Sep 2017, at 22:27, Cág <ca6c@bitmessage.ch> 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
> 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.

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


Jakub



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Shiz
Details
Message ID
<241E8EA7-EC60-4FDF-8CB4-8DF55E0762C1@student.tudelft.nl>
In-Reply-To
<3B3AC404-2958-4FF1-B54A-586130A89222@jirutka.cz> (view parent)
Sender timestamp
1504367075
DKIM signature
missing
Download raw message
> On 2 Sep 2017, at 13:09, Jakub Jirutka <jakub@jirutka.cz> wrote:
> 
> On 1. Sep 2017, at 22:27, Cág <ca6c@bitmessage.ch> 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.

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.

>> 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.
> 
> 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
Jakub Jirutka
Details
Message ID
<60D510F7-8D5E-42BA-9AB0-71BE0231AA0D@jirutka.cz>
In-Reply-To
<241E8EA7-EC60-4FDF-8CB4-8DF55E0762C1@student.tudelft.nl> (view parent)
Sender timestamp
1504368374
DKIM signature
missing
Download raw message
>>>> 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.
> 
> 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.
> 
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…

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

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

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

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

---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---