Re: Application as Trusted User
Addendum! On 3/14/23 12:29, Anton Hvornum wrote:
Hi!
I hereby apply to become a Trusted User! According to ChatGPT3 becoming a TU is like becoming a wizard, I will learn how to cast complex spells on package bugs and conjure releases. And apparently I get to wear a robe too so sign me up!
I have the following sponsors:
* Artafinde * dvzrv (David will happily let someone else sponsor if they feel like it tho)
dvzrv hands over the torch to alerque to distribute the sponsorships more evenly. So new sponsor list is: * Artafinde * alerque
My involvement spans mostly across maintaining archinstall, but I also have a finger in archweb, repod, archiso, mkinitcpio and lately I've become a mirror admin. So I'm getting pretty well rounded.
Some links to profiles, ongoing projects and involvements: * GitHub: https://github.com/Torxed/ * GitLab: https://gitlab.archlinux.org/torxed * Archinstall: https://github.com/archlinux/archinstall * Flyspray/Bugs: https://bugs.archlinux.org/user/15638 * AUR package: https://aur.archlinux.org/packages/archinstall-git (I have a few others that I've cleaned out as they were my very first AUR packages that never gained popularity) * ArchISO: https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/251 * mkinitcpio: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... & https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... * repod: https://gitlab.archlinux.org/archlinux/repod/-/merge_requests?scope=all&state=merged&author_username=torxed (Mainly contributed in terms of PR reviews and participating in developer discussions) Aside from the above, I'm also active on BBS forum, IRC, Reddit, Discord and Matrix in various channels. I mainly run all the archinstall related channels and servers. But I'm subscribed to more or less all the mailing lists, but specifically `arch-general`, `arch-mirrors` and `arch-projects`. My goal is to ease packaging and bug reports, as of today I have to rely on others to do packaging for projects I maintain and administrate. The main packages I aim to co-maintain the following packages: * python-pyparted (added 2023-03-14) * python * synapse * keycloak * rdesktop * python-* (there's a 50+ list I would like to help out with that I use every day) I'm sure the list will grow, but those are the main ones I have my eye on currently. Overall, I'm a very enthusiastic tech geek and I'm committed to enhance the Arch Linux experience further in various ways. I've been an active developer for years, have plenty of devops experience as well as a programming and security background. I plan to translate my experience into the Arch Linux echo system as well as offer my support to the community in any way I can.
I'm aiming to continue the work on the above, but gradually I'll also help out with testing and packaging of Python libraries.
//Anton "Torxed" Hvornum
Hello On 14/03/2023 14:47, Anton Hvornum wrote:
[..]
dvzrv hands over the torch to alerque to distribute the sponsorships more evenly. So new sponsor list is: * Artafinde * alerque I confirm my sponsorship.
[..] * GitHub: https://github.com/Torxed/ * GitLab: https://gitlab.archlinux.org/torxed * Archinstall: https://github.com/archlinux/archinstall * Flyspray/Bugs: https://bugs.archlinux.org/user/15638 * AUR package: https://aur.archlinux.org/packages/archinstall-git (I have a few others that I've cleaned out as they were my very first AUR packages that never gained popularity) * ArchISO: https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/251 * mkinitcpio: https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... & https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... * repod: https://gitlab.archlinux.org/archlinux/repod/-/merge_requests?scope=all&state=merged&author_username=torxed (Mainly contributed in terms of PR reviews and participating in developer discussions)
Great to see active development project there :)
Aside from the above, I'm also active on BBS forum, IRC, Reddit, Discord and Matrix in various channels. I mainly run all the archinstall related channels and servers. But I'm subscribed to more or less all the mailing lists, but specifically `arch-general`, `arch-mirrors` and `arch-projects`.
My goal is to ease packaging and bug reports, as of today I have to rely on others to do packaging for projects I maintain and administrate. The main packages I aim to co-maintain the following packages: * python-pyparted (added 2023-03-14) * python This involves a bootstrapping mechanism and is part of core not community. * synapse synapse or matrix-synapse? * keycloak * rdesktop Both keycloak and rdesktop have a few maintainers (3+) * python-* (there's a 50+ list I would like to help out with that I use every day)
I'm sure the list will grow, but those are the main ones I have my eye on currently.
Cheers, -- Leonidas Spyropoulos Trusted User & DevOps PGP: 59E43E106B247368
On 3/14/23 18:34, Leonidas Spyropoulos wrote:
Hello
On 14/03/2023 14:47, Anton Hvornum wrote:
... I aim to co-maintain the following packages: * python-pyparted (added 2023-03-14) * python This involves a bootstrapping mechanism and is part of core not community. That is true, I might have been a bit fuzzy in the description there. I aim to help out with Python releases by helping out testing and submitting patches to upstream whenever there is an issue. For instance by looking at https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/m... and helping debug situations like https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... * synapse synapse or matrix-synapse? Good catch, matrix-synapse :) * keycloak * rdesktop Both keycloak and rdesktop have a few maintainers (3+) Noted, I'll keep an eye on them tho and help test them whenever they're in testing for instance.
//Anton
On Tue, 2023-03-14 at 15:47 +0100, Anton Hvornum wrote:
dvzrv hands over the torch to alerque to distribute the sponsorships more evenly. So new sponsor list is: * Artafinde * alerque
Sponsorship confirmed.
On 14/03/2023 20:34, Caleb Maclennan wrote:
On Tue, 2023-03-14 at 15:47 +0100, Anton Hvornum wrote:
dvzrv hands over the torch to alerque to distribute the sponsorships more evenly. So new sponsor list is: * Artafinde * alerque
Sponsorship confirmed.
This marks the beginning of the discussion period which will conclude in two weeks on 2023-03-29. The voting will start on the same day and conclude on 2023-04-05. Cheers, -- Leonidas Spyropoulos Trusted User & DevOps PGP: 59E43E106B247368
Hi, On 14/03/2023 15:47, Anton Hvornum wrote:
Addendum!
On 3/14/23 12:29, Anton Hvornum wrote:
Hi!
My involvement spans mostly across maintaining archinstall, but I also have a finger in archweb, repod, archiso, mkinitcpio and lately I've become a mirror admin. So I'm getting pretty well rounded.
Some links to profiles, ongoing projects and involvements:
* GitHub: https://github.com/Torxed/ * GitLab: https://gitlab.archlinux.org/torxed * Archinstall: https://github.com/archlinux/archinstall * Flyspray/Bugs: https://bugs.archlinux.org/user/15638 * AUR package: https://aur.archlinux.org/packages/archinstall-git (I have a few others that I've cleaned out as they were my very first AUR packages that never gained popularity)
Actually this is a package you co-maintain, any other packages you have maintained in the AUR? [1] It's hard get a feel about your packaging history without any examples to look at. [1] https://aur.archlinux.org/packages?K=Torxed&SeB=m Greetings, Jelle
Hi,
Actually this is a package you co-maintain, any other packages you have maintained in the AUR? [1]
It's hard get a feel about your packaging history without any examples to look at. It's a valid question, and my response would be that I don't think my AUR-packaging experience is my super power yet (or at least nothing to brag about). If anything it's my involvement with developing Arch Linux tooling,
On 3/22/23 19:37, Jelle van der Waa wrote: participate and being involved in projects[1][2][3][4][5][6][7][8][9][10] and helping the community. Those are what made me to apply for a TU role. I have a deep rooted willingness to learn if given the opportunity and I've seen the need and calling from people to help with orphaned packages and every now and then packages pop up that I use, love and would love to help out carry on the packaging of - but can't due to my current role. I see this as an opportunity to gently ease my way into it while still being very familiar with the Arch echo system and how a lot of the packages are packaged in general terms. I honestly also don't have many packages that I would need to put into AUR that I feel others would want or need. As a person I'm a very "hands-on" person. I need practical reasons and examples for doings things - so co-maintaining packages would be the best way for me to learn and gradually shoulder more and more responsibilities. And I hope my involvement in packaging[11] and distributing archinstall releases[12] for the last 2 years (anniversary[13] coming up in the 1:st of April this year) would count for something. Not trying to apply or win sympathy points, but it has been a lot of work and I hope it counts for something. I will mention that I have packaged a few personal projects on AUR >5 years ago: * slimDHCP[14] (Was in AUR ~2018, but quality of the PKGBUILD was not the best) * slimDNS[15] (Also in AUR, a bit older than slimDHCP) * slimSMTP[16] (same here) I think I had a few more but they've been deleted since long ago. Again, they're by no means production worthy examples and quite outdated frankly and I learned a lot back then and since. [1] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/251 [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [3] https://gitlab.archlinux.org/archlinux/archiso/-/issues/65 [4] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [5] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [6] https://gitlab.archlinux.org/archlinux/repod/-/issues/14 [7] https://gitlab.archlinux.org/archlinux/repod/-/merge_requests/21 [8] https://github.com/Torxed/archoffline [9] https://github.com/archlinux/archweb/pulls?q=is%3Apr+author%3ATorxed [10] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/294 [11] https://github.com/archlinux/archinstall/commits/master/PKGBUILD [12] https://github.com/archlinux/archinstall/releases [13] https://archlinux.org/news/installation-medium-with-installer/ [14] https://gist.github.com/Torxed/206a15e5d11b2252c696c32ed394caaf [15] https://gist.github.com/Torxed/5c872cf8b673afc74927cb31a1d4e5e5 [16] https://gist.github.com/Torxed/5a41155a0dd88d518c404e94b56a8a8a
[1] https://aur.archlinux.org/packages?K=Torxed&SeB=m
Greetings,
Jelle
All the best, //Anton
On 3/22/23 22:34, Anton Hvornum wrote:
Hi,
Actually this is a package you co-maintain, any other packages you have maintained in the AUR? [1]
It's hard get a feel about your packaging history without any examples to look at. It's a valid question, and my response would be that I don't think my AUR-packaging experience is my super power yet (or at least nothing to brag about). If anything it's my involvement with developing Arch Linux tooling,
On 3/22/23 19:37, Jelle van der Waa wrote: participate and being involved in projects[1][2][3][4][5][6][7][8][9][10] and helping the community. Those are what made me to apply for a TU role.
I have a deep rooted willingness to learn if given the opportunity and I've seen the need and calling from people to help with orphaned packages and every now and then packages pop up that I use, love and would love to help out carry on the packaging of - but can't due to my current role. I see this as an opportunity to gently ease my way into it while still being very familiar with the Arch echo system and how a lot of the packages are packaged in general terms. I honestly also don't have many packages that I would need to put into AUR that I feel others would want or need.
As a person I'm a very "hands-on" person. I need practical reasons and examples for doings things - so co-maintaining packages would be the best way for me to learn and gradually shoulder more and more responsibilities. And I hope my involvement in packaging[11] and distributing archinstall releases[12] for the last 2 years (anniversary[13] coming up in the 1:st of April this year) would count for something. Not trying to apply or win sympathy points, but it has been a lot of work and I hope it counts for something.
I will mention that I have packaged a few personal projects on AUR >5 years ago:
* slimDHCP[14] (Was in AUR ~2018, but quality of the PKGBUILD was not the best) * slimDNS[15] (Also in AUR, a bit older than slimDHCP) * slimSMTP[16] (same here)
I think I had a few more but they've been deleted since long ago. Again, they're by no means production worthy examples and quite outdated frankly and I learned a lot back then and since.
[1] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/251 [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [3] https://gitlab.archlinux.org/archlinux/archiso/-/issues/65 [4] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [5] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [6] https://gitlab.archlinux.org/archlinux/repod/-/issues/14 [7] https://gitlab.archlinux.org/archlinux/repod/-/merge_requests/21 [8] https://github.com/Torxed/archoffline [9] https://github.com/archlinux/archweb/pulls?q=is%3Apr+author%3ATorxed [10] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/294 [11] https://github.com/archlinux/archinstall/commits/master/PKGBUILD [12] https://github.com/archlinux/archinstall/releases [13] https://archlinux.org/news/installation-medium-with-installer/ [14] https://gist.github.com/Torxed/206a15e5d11b2252c696c32ed394caaf [15] https://gist.github.com/Torxed/5c872cf8b673afc74927cb31a1d4e5e5 [16] https://gist.github.com/Torxed/5a41155a0dd88d518c404e94b56a8a8a
[1] https://aur.archlinux.org/packages?K=Torxed&SeB=m
Greetings,
Jelle
All the best, //Anton
Hi Anton, As there isn't much packages to review anymore, which is unfortunate, I'd like to ask if you can improve the only package you currently co-maintain in the AUR currently: archinstall-git. I'd love to see it being upgraded to the latest python ecosystem standards using (PEP 517 and friends). Furthermore it lacks proper provides/conflicts declaration on the none -git named archinstall package itself (both provide/conflict the same meta declaration, but in terms of correctness it should always conflict on the none git pkgname). On top It lacks `git` as makedepends. It should also provide a pkgver() function as documented in the packaging guidelines, currently different states would yield to the same pkgver which is not good. Cheers, Levente
On 3/22/23 22:34, Anton Hvornum wrote:
Hi,
Actually this is a package you co-maintain, any other packages you have maintained in the AUR? [1]
It's hard get a feel about your packaging history without any examples to look at. It's a valid question, and my response would be that I don't think my AUR-packaging experience is my super power yet (or at least nothing to brag about). If anything it's my involvement with developing Arch Linux tooling,
On 3/22/23 19:37, Jelle van der Waa wrote: participate and being involved in projects[1][2][3][4][5][6][7][8][9][10] and helping the community. Those are what made me to apply for a TU role.
I have a deep rooted willingness to learn if given the opportunity and I've seen the need and calling from people to help with orphaned packages and every now and then packages pop up that I use, love and would love to help out carry on the packaging of - but can't due to my current role. I see this as an opportunity to gently ease my way into it while still being very familiar with the Arch echo system and how a lot of the packages are packaged in general terms. I honestly also don't have many packages that I would need to put into AUR that I feel others would want or need.
As a person I'm a very "hands-on" person. I need practical reasons and examples for doings things - so co-maintaining packages would be the best way for me to learn and gradually shoulder more and more responsibilities. And I hope my involvement in packaging[11] and distributing archinstall releases[12] for the last 2 years (anniversary[13] coming up in the 1:st of April this year) would count for something. Not trying to apply or win sympathy points, but it has been a lot of work and I hope it counts for something.
I will mention that I have packaged a few personal projects on AUR >5 years ago:
* slimDHCP[14] (Was in AUR ~2018, but quality of the PKGBUILD was not the best) * slimDNS[15] (Also in AUR, a bit older than slimDHCP) * slimSMTP[16] (same here)
I think I had a few more but they've been deleted since long ago. Again, they're by no means production worthy examples and quite outdated frankly and I learned a lot back then and since.
[1] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/251 [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [3] https://gitlab.archlinux.org/archlinux/archiso/-/issues/65 [4] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [5] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/merge... [6] https://gitlab.archlinux.org/archlinux/repod/-/issues/14 [7] https://gitlab.archlinux.org/archlinux/repod/-/merge_requests/21 [8] https://github.com/Torxed/archoffline [9] https://github.com/archlinux/archweb/pulls?q=is%3Apr+author%3ATorxed [10] https://gitlab.archlinux.org/archlinux/archiso/-/merge_requests/294 [11] https://github.com/archlinux/archinstall/commits/master/PKGBUILD [12] https://github.com/archlinux/archinstall/releases [13] https://archlinux.org/news/installation-medium-with-installer/ [14] https://gist.github.com/Torxed/206a15e5d11b2252c696c32ed394caaf [15] https://gist.github.com/Torxed/5c872cf8b673afc74927cb31a1d4e5e5 [16] https://gist.github.com/Torxed/5a41155a0dd88d518c404e94b56a8a8a
[1] https://aur.archlinux.org/packages?K=Torxed&SeB=m
Greetings,
Jelle
All the best, //Anton
Hi Anton,
As there isn't much packages to review anymore, which is unfortunate, I'd like to ask if you can improve the only package you currently co-maintain in the AUR currently: archinstall-git.
I'd love to see it being upgraded to the latest python ecosystem standards using (PEP 517 and friends). Archinstall does have an updated build and install echosystem upstream as we use PEP 517 compliant tools[1]. I've been focusing outright on getting a release out so I haven't had time to push those changes during
On 3/26/23 13:43, Levente Polyak wrote: this discussion period to the AUR PKGBUILD, but these changes have been made in the upstream package PKGBUILD since long ago. I did take some time just now to update the AUR PKGBUILD.
Furthermore it lacks proper provides/conflicts declaration on the none -git named archinstall package itself (both provide/conflict the same meta declaration, but in terms of correctness it should always conflict on the none git pkgname).
I assumed (incorrectly?) that since both have 'provides' that point to 'python-archinstall' they detect the conflict automatically. Would 'conflicts=(python-archinstall-git)' be appropriate in the non -git package or should it be 'conflicts=(archinstall-git)' as the package is called 'archinstall-git' not 'python-archinstall-git'?
On top It lacks `git` as makedepends.
Thanks, that is fixed!
It should also provide a pkgver() function as documented in the packaging guidelines, currently different states would yield to the same pkgver which is not good.
This is now implemented in both PKGBUILD's as well, thank you! Just to shed some more info on the decisions during packaging. One change was to remove flit[1] and homogenizing to the pypa 'setuptools', 'build' and 'installer' toolings (which serves as reference implementations in my mind and should hopefully be more stable) as flit was causing sudden and unexpected issues. And we keep 'twine' for interacting with PyPi instead. We also made efforts ~1 year ago to make archinstall reproducible (was simple enough I think, thanks Dave (IIRC)!) Next up is to introduce our first dependency[2][3]. That change will be represented in the PKGBUILD once the python-pyparted is out of testing[2]. Thank you for your feedback btw, it's appreicated and served as a good reminder that the PKGBUILD in the AUR had not been updated to reflect the state of the PKGBUILD in the upstream GitHub repo[5]. I've strived to follow the Python package guidelines[4] as closely as I can and hope that's reflected in the PKGBUILD's now. [1] https://github.com/archlinux/archinstall/pull/1655 [2] https://archlinux.org/packages/community-testing/x86_64/python-pyparted/ [3] https://github.com/archlinux/archinstall/pull/1604 [4] https://wiki.archlinux.org/title/Python_package_guidelines [5] https://github.com/archlinux/archinstall/blob/master/PKGBUILD //Anton
On 14/03/2023 21:21, Leonidas Spyropoulos wrote:
On 14/03/2023 20:34, Caleb Maclennan wrote:
On Tue, 2023-03-14 at 15:47 +0100, Anton Hvornum wrote:
dvzrv hands over the torch to alerque to distribute the sponsorships more evenly. So new sponsor list is: * Artafinde * alerque
Sponsorship confirmed.
This marks the beginning of the discussion period which will conclude in two weeks on 2023-03-29. The voting will start on the same day and conclude on 2023-04-05.
Cheers,
Discussion period finished and the vote is up. Please cast your votes: https://aur.archlinux.org/tu/144 Thanks, -- Leonidas Spyropoulos Trusted User & DevOps PGP: 59E43E106B247368
On 3/29/23 15:43, Anton Hvornum wrote:
On 3/22/23 22:34, Anton Hvornum wrote: Furthermore it lacks proper provides/conflicts declaration on the none -git named archinstall package itself (both provide/conflict the same meta declaration, but in terms of correctness it should always conflict on the none git pkgname). I assumed (incorrectly?) that since both have 'provides' that point to 'python-archinstall' they detect the conflict automatically. Would 'conflicts=(python-archinstall-git)' be appropriate in the non -git
On 3/26/23 13:43, Levente Polyak wrote: package or should it be 'conflicts=(archinstall-git)' as the package is called 'archinstall-git' not 'python-archinstall-git'?
Theoretically the assumption about `python-archinstall` is correct, but let me shortly explain why it still matters: Such provides are just additional metadata, often also just used to replace a former package name. Such can a lot easier change or vanish. Another reason: using python2 here just to have a simple visualization of the issue (could be anything i reality): `python-archinstall` correctly states it provides a python library part of archinstall. Imagine a scenario where there would by a python2 or whatever version then declaring `python-archinstall` would be wrong as that's not what it provides or conflicts, it conflicts on `usr/bin/archinstall`. A good practice that just solves all the issues is to simply declare provides/conflicts on the canonical none-special variant: In this case `archinstall`. To the second part: I do see cases where the canonical none-special variant does conflict on special purpose variants. That should not be done. It's the responsibility of the special purpose variants to conflict on the canonical variant. Let me also picture this really quickly: Imagine someone would be adding new special purpose variants, that could happen to any arbitrary point in time. If this rule is not followed, that would mean the canonical variant needs to be updated whenever a new special purpose variant materializes. This would not be much fun :) On the other hand, if the rule is followed that special purpose variants must declare its conflict against the canonical variant, then automatically any case is covered at whatever time a new variant materializes. So the take on this should be to always follow those 2 simple rules to be happy and safe 😺: - always (at least additionally) conflict on the actual canonical package in the special purpose variants - never conflict on special purpose variants in the canonical variant package. Notify them instead and let that be the responsibility of the special purpose variants.
Thank you for your feedback btw, it's appreicated and served as a good reminder that the PKGBUILD in the AUR had not been updated to reflect the state of the PKGBUILD in the upstream GitHub repo[5]. I've strived to follow the Python package guidelines[4] as closely as I can and hope that's reflected in the PKGBUILD's now.
I'm always happy to provide feedback and help each other out. Thank you for being open and reflective and also asking questions you'd like to get an opinion on. I wish you good luck for the vote, Levente
On 3/30/23 11:16, Levente Polyak wrote:
On 3/29/23 15:43, Anton Hvornum wrote:
On 3/22/23 22:34, Anton Hvornum wrote: Furthermore it lacks proper provides/conflicts declaration on the none -git named archinstall package itself (both provide/conflict the same meta declaration, but in terms of correctness it should always conflict on the none git pkgname). I assumed (incorrectly?) that since both have 'provides' that point to 'python-archinstall' they detect the conflict automatically. Would 'conflicts=(python-archinstall-git)' be appropriate in the non -git
On 3/26/23 13:43, Levente Polyak wrote: package or should it be 'conflicts=(archinstall-git)' as the package is called 'archinstall-git' not 'python-archinstall-git'?
Theoretically the assumption about `python-archinstall` is correct, but let me shortly explain why it still matters: Such provides are just additional metadata, often also just used to replace a former package name. Such can a lot easier change or vanish. Another reason: using python2 here just to have a simple visualization of the issue (could be anything i reality): `python-archinstall` correctly states it provides a python library part of archinstall. Imagine a scenario where there would by a python2 or whatever version then declaring `python-archinstall` would be wrong as that's not what it provides or conflicts, it conflicts on `usr/bin/archinstall`.
A good practice that just solves all the issues is to simply declare provides/conflicts on the canonical none-special variant: In this case `archinstall`.
To the second part: I do see cases where the canonical none-special variant does conflict on special purpose variants. That should not be done. It's the responsibility of the special purpose variants to conflict on the canonical variant. Let me also picture this really quickly: Imagine someone would be adding new special purpose variants, that could happen to any arbitrary point in time. If this rule is not followed, that would mean the canonical variant needs to be updated whenever a new special purpose variant materializes. This would not be much fun :) On the other hand, if the rule is followed that special purpose variants must declare its conflict against the canonical variant, then automatically any case is covered at whatever time a new variant materializes.
So the take on this should be to always follow those 2 simple rules to be happy and safe 😺: - always (at least additionally) conflict on the actual canonical package in the special purpose variants - never conflict on special purpose variants in the canonical variant package. Notify them instead and let that be the responsibility of the special purpose variants.
Thank you for your feedback btw, it's appreicated and served as a good reminder that the PKGBUILD in the AUR had not been updated to reflect the state of the PKGBUILD in the upstream GitHub repo[5]. I've strived to follow the Python package guidelines[4] as closely as I can and hope that's reflected in the PKGBUILD's now.
I'm always happy to provide feedback and help each other out. Thank you for being open and reflective and also asking questions you'd like to get an opinion on.
Thank you for taking the time to explain it very elegantly! It's really appreciated.
I wish you good luck for the vote, Again thank you! Hoping for the best! :D
//Anton
On 2023-03-30 11:21, Leonidas Spyropoulos wrote:
Discussion period finished and the vote is up.
Please cast your votes: https://aur.archlinux.org/tu/144
The voting period has ended and the results are in. Yes: 24 No: 9 Abstain: 12 Total: 45 The ayes have it and Torxed well be receiving a copy of the keys to the castle, and map to the subversion dungeons, a long lecture about the ropes, and maybe some tips on how not to hang himself in the rigging (or mess up any packages). The on-boarding process has a lot of steps but expect Anton to start showing up in the role that was Trusted User, now known as Package Maintainer. Caleb
participants (6)
-
Anton Hvornum
-
Caleb Maclennan
-
Caleb Maclennan
-
Jelle van der Waa
-
Leonidas Spyropoulos
-
Levente Polyak