[gentoo-dev] [PATCH] glep-0068: Add new element
Signed-off-by: Michał Górny --- glep-0068.rst | 62 --- 1 file changed, 59 insertions(+), 3 deletions(-) diff --git a/glep-0068.rst b/glep-0068.rst index d8fc379..5b7e2b9 100644 --- a/glep-0068.rst +++ b/glep-0068.rst @@ -4,10 +4,10 @@ Title: Package and category metadata Author: Michał Górny Type: Standards Track Status: Final -Version: 1.1 +Version: 1.2 Created: 2016-03-14 -Last-Modified: 2020-05-06 -Post-History: 2016-03-16, 2018-02-20 +Last-Modified: 2020-09-16 +Post-History: 2016-03-16, 2018-02-20, 2020-09-16 Content-Type: text/x-rst Requires: 67 Replaces: 34, 46, 56 @@ -149,6 +149,10 @@ element can contain, in any order: languages (at most one for each language), as detailed in `Slot descriptions`_. +- at most one element containing version + constraints used to determine stabilization candidates, as detailed + in `Stabilization candidates`_. + - zero or more elements, possibly restricted to specific package versions (at most one for each version) whose presence indicates that the appropriate ebuilds are suitable for simultaneously @@ -199,6 +203,25 @@ The element can contain the following elements: - at most one element describing the role of subslots (all of them) as text. +Stabilization candidates + +Each element describes version +constraints used to determine package versions eligible +for stabilization. Should this element be missing, the tooling assumes +a default of any version with any keywords present (i.e. the equivalent +of ``>=0``). + +The element can contain the following +elements: + +- one or more elements, each containing a version + constraint in the format matching EAPI 0 dependency specification + with the package category and name parts omitted, e.g. ``<1.7``. + The tooling considers any ebuild version that satisfies the constraint + and has any keywords. If multiple constraints are provided, every one + of them is matched separately, and multiple stabilization candidates + can be reported. + USE flag descriptions ~ Each element describes USE flags of a package (in specific @@ -378,6 +401,39 @@ package version restrictions and maintainer descriptions were also implicitly allowed on them. Since neither of the two was allowed by GLEP 46, this specification disallows them. +Stabilization candidates + +Version 1.2 of the specification adds stabilization candidate versions. +The primary goal of this is to provide a more fine-grained control +of tooling reporting stabilization candidates. Previously, pkgcheck +reported only the newest keyworded version that was eligible for +stabilization according to the 30-day testing period. This had two +limitations. + +Firstly, it did not account for development branches properly +and reported them as stabilization candidates. While we could +technically blacklist ``_alpha``, ``_beta``, ``_rc`` versions, +this would not work for all packages. Some GNOME and XFCE packages use +odd numbers in minor version to indicate development branch. +On the other hand, there are stagnant packages that stay in pre-release +state for months, and stabilizing these versions also makes sense. + +Secondly, it did not account for software maintaining multiple parallel +stable branches. As soon as the newer version became eligible +for stabilization, new releases of the older branches were not reported. +In some cases, users are bound to old versions because of dependencies +(e.g. on Python 2.7). + +The proposed ‘whitelist-override’ syntax aims to help with both cases. +The default preserves current behavior. A single override such +as ``<1.7`` can be used to explicitly ignore development branch, +and request stabilization candidates from earlier versions. Multiple +version constraints (say, ``<5.9`` and ``<5.5``) can be used to request +monitoring multiple upstream branches. + +This information can also be consumed by users to opt-out of development +versions and keep their systems running potential stable candidates. + Backwards Compatibility === -- 2.28.0
Re: [gentoo-dev] rfc: kubernetes packaging
On Mon, Sep 14, 2020 at 12:30:48PM +0200, Marc Schiffbauer wrote: > * William Hubbs schrieb am 14.09.20 um 00:39 Uhr: > > All, > > > > I would like to get some thoughts on kubernetes packaging. > > > > When I started maintaining it in Gentoo, it was packaged as 7 ebuilds > > (one per executable), and only one of them was marked stable. > > > > Since we normally do not split up monorepos into separate packages, I > > started moving everything over to one kubernetes ebuild. > > Now a bug has > > been opened which has a good case for kubeadm being a package on its > > own, so I have done that [1]. > > > > I need to know the best way to proceed, so I'll throw out a couple > > of questions: > > > > 1) should I bring back the split packages and lastrites > > sys-cluster/kubernetes? > > > > 2) should I just bring back other split packages that need to be split > > as I find them? > > > > What do folks think would be the best way for us to package Kubernetes? > > > Interesting. > > So it seems like at least kubeadm and kube-apiserver need to be in > seperate packages. > > I am not a kubernetes guy, but would SLOTting be an option? Like > postgresql for example where you need both versions, old a new to do > database migration. I'm not really interested in slotting; that becomes complicated really quickly -- renaming all of the binaries to version-specific names writing an eselect module, etc. > If this is not an option I would say this is a case for split package > and perhaps a meta-package bringing all of them together. Thinking about it more, the split packages are going to be the best setup. However, a meta package would only be valuable if all parts of kubernetes are needed on the same machine, and that isn't the case most of the time from what I've been told. If folks think that single case justifies one, let me know. My thought is that the meta package, if I create one, should only have a two level version number and use * dependencies to match all package versions in that range. What do others think? is it worth a meta package for the case of having all kubernetes binaries on one machine? If so, what do you think about my suggestion of the minor versions for the meta package? William signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/matplotlib-python2
All revdeps are already masked for removal, so let's add it to their pmask: # Michał Górny (2020-07-13) # Python 2 dev-python/pillow revdeps with extended removal time. # Also the only revdeps of dev-python/matplotlib-python2. # Removal in 90 days. Bug #729672. dev-python/matplotlib-python2 -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: sys-fs/ufsutils
# Sam James (2020-09-15) # No longer exists upstream, stuck on long-obsolete EAPI 4, # and fails to build with glibc-2.32. # Vestige of Gentoo/FreeBSD. # bug #715506, #737892, #740916, #547244. sys-fs/ufsutils signature.asc Description: Message signed with OpenPGP
[gentoo-dev] Last rites: net-nntp/sn
# Stephan Hartmann (2020-09-15) # Stuck on EAPI 4, does not build, homepage gone, no maintainer. # Removal in 30 days. See bugs #717188, #725212, #736607, # #742158. net-nntp/sn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stabilisation of app-admin/ansible-2.10.0
Hi, The current state is that the Ansible in tree is not working due to fact that it misses core modules. I'd say 2.10.0 should be masked, as ~arch or stable arch, it does not work, then revbump to use bundle package, not ansible-base. If maintainer want to split it into ansible-base + separated ebuilds for modules, then maintainer should prepare a news item, as the update replaces working Ansible with something that cannot work by itself, and there's no interfaces to take in rest of needed parts as by now. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stabilisation of app-admin/ansible-2.10.0
On 15/09/2020 12:03, Marek Szuba wrote: > Dear Matthew, > > I notice that you have recently stabilised app-admin/ansible-2.10.0 in > Gentoo. Ansible upstream has introduced in that version major changes to > their project structure [1] which given the current state of Ansible > packaging in Gentoo can be considered severely breaking for our users. > Therefore, please: > 1. Revert stabilisation of 2.10.0, and > 2. Either >* by no means remove 2.9.12 from the tree for the time being, and > before attempting to stabilise 2.10+ again either prepare a news item > warning the users about upcoming breaking changes or package a suitable > set of formerly-core modules; or >* simply pull the current incarnation of 2.10.0 from the tree and > only reintroduce it once the ansible (*not* ansible-base) on PyPI has > actually been upgraded to 2.10. > > > Explanation for the ML: > > Starting with version 2.10, the upstream package previously known as > ansible is formally known as "ansible-base" and only provides the bare > minimum of functionality - the core programs, some documentation, and a > tiny subset of modules and plugins to allow for a functioning > controller. All the other modules which were previously part of core > ansible (see [2]) are now independent modules. > > Note that this only pertains to upstream packages of Ansible released on > GitHub. On PyPI, "ansible" will continue to bundle the "core" modules; > this is explicitly mentioned in several places in [1]. The problem is, > =app-admin/ansible-2.10.0 has quietly replaced pypi:ansible with > pypi:ansible-base in SRC_URI. This may or may not have had something to > do with the fact pypi:ansible has not been updated to 2.10.0 yet (for > now it's only pre-releases for that branch). > > References: > > [1] https://github.com/ansible-collections/overview/blob/main/README.rst > [2] > https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in > If they are indeed going to release a "normal" version with core modules, I'm in favour of separating ansible and ansible-base, which is what upstream did in its PPA. That would mean removing ansible 2.10 from the tree and re-adding it as ansible-base 2.10. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Stabilisation of app-admin/ansible-2.10.0
Dear Matthew, I notice that you have recently stabilised app-admin/ansible-2.10.0 in Gentoo. Ansible upstream has introduced in that version major changes to their project structure [1] which given the current state of Ansible packaging in Gentoo can be considered severely breaking for our users. Therefore, please: 1. Revert stabilisation of 2.10.0, and 2. Either * by no means remove 2.9.12 from the tree for the time being, and before attempting to stabilise 2.10+ again either prepare a news item warning the users about upcoming breaking changes or package a suitable set of formerly-core modules; or * simply pull the current incarnation of 2.10.0 from the tree and only reintroduce it once the ansible (*not* ansible-base) on PyPI has actually been upgraded to 2.10. Explanation for the ML: Starting with version 2.10, the upstream package previously known as ansible is formally known as "ansible-base" and only provides the bare minimum of functionality - the core programs, some documentation, and a tiny subset of modules and plugins to allow for a functioning controller. All the other modules which were previously part of core ansible (see [2]) are now independent modules. Note that this only pertains to upstream packages of Ansible released on GitHub. On PyPI, "ansible" will continue to bundle the "core" modules; this is explicitly mentioned in several places in [1]. The problem is, =app-admin/ansible-2.10.0 has quietly replaced pypi:ansible with pypi:ansible-base in SRC_URI. This may or may not have had something to do with the fact pypi:ansible has not been updated to 2.10.0 yet (for now it's only pre-releases for that branch). References: [1] https://github.com/ansible-collections/overview/blob/main/README.rst [2] https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
On Tue, 15 Sep 2020 09:12:58 +0200 Toralf Förster wrote: > However this doesn't cover bugs filed a while ago and are not be fixed in > current stable. A mitigation would be it wouldn't file a stabilization req if there was already one open. Basically means as soon as there's one stable req, it reverts to "manual mode", as you either fix the problem that blocked stabilization, or you ship a new one and re-point the stabilization request to that instead. pgpFSehgOrpfp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
On 9/15/20 8:42 AM, Michał Górny wrote: > Do you have any suggestions how we could improve this? A (naive) approach would be to have something like auto_stable_after_x_days=n somewhere and a bot which checks whether a bug was opened related to the last version. However this doesn't cover bugs filed a while ago and are not be fixed in current stable. -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How to stabilize packages with frequent release cycles?
On 9/15/20 9:42 AM, Michał Górny wrote: > Hi, > > The regular stabilization workflow works for the majority of packages. > However, it makes little sense for packages with frequent release > cycles. Examples of these are boto3/botocore (daily release cycle) or > hypothesis (upstream conflates commits with releases). > > When the latest release remains 'latest ~arch' for less than 3 days, > stabilizing it after 30 days makes little sense. After all, people with > frequent upgrade cycle will test it for no more than that, and people > with infrequent upgrade cycle may miss the version entirely. Isn't the 30 days just a recommendation, not a strict rule? > > In the end, we stabilize an entirely arbitrary version at an arbitrary > point in time, and even if users were willing to give it better testing, > they can't guess which version will be the next stable candidate. > > Do you have any suggestions how we could improve this? Just use maintainer's discretion on them. For example, see how youtube-dl and vivaldi are stabilized, both having frequent releases. In vivaldi's case the security updates make fast-stabilization a mandatory step pretty much and for youtube-dl you want to keep it compatible with "today". Anyway, that's one way. Not like every stable version in the tree works either. -- juippis signature.asc Description: OpenPGP digital signature
[gentoo-dev] How to stabilize packages with frequent release cycles?
Hi, The regular stabilization workflow works for the majority of packages. However, it makes little sense for packages with frequent release cycles. Examples of these are boto3/botocore (daily release cycle) or hypothesis (upstream conflates commits with releases). When the latest release remains 'latest ~arch' for less than 3 days, stabilizing it after 30 days makes little sense. After all, people with frequent upgrade cycle will test it for no more than that, and people with infrequent upgrade cycle may miss the version entirely. In the end, we stabilize an entirely arbitrary version at an arbitrary point in time, and even if users were willing to give it better testing, they can't guess which version will be the next stable candidate. Do you have any suggestions how we could improve this? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
