Gentoo Archives: gentoo-dev

From: Alexey Sokolov <alexey+gentoo@××××××××.org>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] feature request: packages.gentoo.org
Date: Fri, 12 Feb 2021 08:05:30
Message-Id: CAHK_jdiO7DHB+WK=vWMB=jB=WGti1LPxAJeVpy4SXaMA3=w9yg@mail.gmail.com
In Reply to: [gentoo-dev] feature request: packages.gentoo.org by Jaco Kroon
1 Hi
2 There is a Packages component at
3 https://bugs.gentoo.org/enter_bug.cgi?product=Websites for reports
4 like this
5
6 пт, 12 февр. 2021 г. в 07:10, Jaco Kroon <jaco@××××××.za>:
7
8 >
9 > Hi,
10 >
11 > Firstly: I was aware of packages.gentoo.org - but only really discovered it in the week - THANK YOU VERY MUCH FOR THIS.
12 >
13 > Not sure whether this is the best place for my request, so if not, please feel free to bat me in the right direction.
14 >
15 > https://packages.gentoo.org/packages/net-misc/asterisk (example) refers.
16 >
17 > I'm the (proxy) maintainer.
18 >
19 > The above URL merely states:
20 >
21 > It seems that version 18.2.0 is available upstream, while the latest version in the Gentoo tree is 16.15.1.
22 >
23 > This is correct. Just looking a little down, it's noted there are two versions currently in tree:
24 >
25 > 16.15.1-r2 : 0
26 > 13.38.1-r2 : 0
27 >
28 > What's not indicated, there are subslots (13 and 16 respectively).
29 >
30 > eshowkw (app-portage/gentoolkit) shows:
31 >
32 > Keywords for net-misc/asterisk:
33 > | | u |
34 > | a a p s a r | n |
35 > | m r h p p s l i i m m | e u s | r
36 > | d a m p p c a x 3 p a s 6 i | a s l | e
37 > | 6 r 6 p p 6 r 8 9 h 6 c 8 p | p e o | p
38 > | 4 m 4 a c 4 c 6 0 a 4 v k s | i d t | o
39 > --------------+-----------------------------+----------+-------
40 > 13.38.1-r2 | + ~ ~ o ~ ~ o + o o o o o o | 7 o 0/13 | gentoo
41 > --------------+-----------------------------+----------+-------
42 > [I]16.15.1-r2 | ~ ~ ~ o ~ ~ o ~ o o o o o o | 7 o 0/16 | gentoo
43 >
44 > Which is currently as intended (yea, I'm behind the times - stable and working in this case over bleeding edge - and nobody other than me is yet pushing me to stable /16, although I have a bug request to package 18 which I intend to start work on today hopefully since I'm working on asterisk stuff for business purposes today anyway).
45 >
46 > 13 is security only release now, and 16 and 18 are the primary branches where 16 is more intended as stable and more fluctuations on 18 still (which precludes me from using it for our company just yet).
47 >
48 > Point being, it would be great if packages.gentoo.org could indicate that in above cases as follows:
49 >
50 > 18.2.0 is available, which is correct, and desired, but if it could also indicate that for the 16 branch there is currently a version of 16.16.0 available, and for 13 things are up to date.
51 >
52 > Would be useful too to indicate that certain branches (eg, 17 in the asterisk case will not be packaged due to being primarily development branches, or at the very least, will not be considered for stabling)
53 >
54 > In other words, guessing I'm looking for some form of "branched versions" support here.
55 >
56 > I know security already has some work around subslots as it was the sec team that requested me to add subslots to net-misc/asterisk.
57 >
58 > And yes ... looks like repology does have a few issues around branches too: https://repology.org/project/asterisk/cves?version=13.38.1
59 >
60 > So I would completely understand if it's not possible to deal with this. As per https://archives.gentoo.org/gentoo-dev/message/b793f4da5a5b5e20a063ea431500a820 there are certain configs that can go into https://gitweb.gentoo.org/sites/soko-metadata.git/ - however, not being a core developer, I don't have (nor am I requesting) access here. May I suggest that in-package metadata (ie, metadata.xml, or even inside the ebuilds) might be a better location for some of this configuration if possible, and if it makes sense? For me the advantage is that as a PM I can submit the required information via PR.
61 >
62 > A description of the branch structure may be more suitable here anyway, because that way other tools can leverage it too?
63 >
64 > Then again, perhaps just looking at the subslots as already available is good enough, in the case of the packages I work on this would indeed be adequate, but it may not be for other packages.
65 >
66 > Looking at repology.org itself, I'm not sure my request is trivial, and I'm not going to ask tons of effort be put into this, but perhaps an interesting challenge for someone at some point.
67 >
68 > Kind Regards,
69 > Jaco