Hi all, we need to do a bit of [core] repository cleanup. In this MD [1] (publicly visible readonly link [2]) we have a list of packages that should leave [core], some maybes that need discussion before moving them and some that should be moved to [core] from the other repositories. If you have more packages, that should not be in [core] anymore or should be moved to it, please add them to the list(s). The general rules for inclusion in [core] are, that we want to - preserve base-devel as a group there - preserve base as a meta-package there - preserve makedepends and depends of a [core] package there The checkdepends and also optdepends of a package may reside in other repositories. As we have a few removals of packages in the list that concern packages only in [core] for historical (or other) reasons, please keep the discussion about them focused on technical reasons as to why they should potentially remain there. Additionally, we have a few orphan packages in [core] that need adoption. Please adopt packages (if you can)! Best, David [1] https://md.archlinux.org/nrXL0ay5Tp6wP-f5M7N8bA# [2] https://md.archlinux.org/s/MliseALTG# -- https://sleepmap.de
If you have more packages, that should not be in [core] anymore or should be moved to it, please add them to the list(s).
Thanks David, here my short additions: - syslinux: is dead and not used in our projects anymore - nano vs. vi one editor could be enough, I can live with both. - reiserfsprogs: dead/abandoned filesystem could be moved out or removed greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org tpowa@archlinux.org Archboot Developer https://bit.ly/archboot
Hey Tobias, On 2022-10-11 12:53:25 (+0200), Tobias Powalowski wrote:
here my short additions: - syslinux: is dead and not used in our projects anymore
I added it to the list. Syslinux itself is still somewhat useful if one doesn't want to deal with grub on legacy boot systems.
- nano vs. vi one editor could be enough, I can live with both.
I'd argue neither needs to be in core. However, nano at least is still somewhat maintained.
- reiserfsprogs: dead/abandoned filesystem could be moved out or removed
Now that my misunderstanding about makedepends has been cleared up, I guess it can just be added to the list (it is make and optdepends of btrfs-progs). Best, David -- https://sleepmap.de
Am Tue, 11 Oct 2022 13:14:12 +0200 schrieb David Runge <dave@sleepmap.de>:
I'd argue neither needs to be in core. However, nano at least is still somewhat maintained.
How comes? Nano is actually pretty well maintained and has seen lots of updates over the past years. See https://git.savannah.gnu.org/cgit/nano.git/log/ https://lists.gnu.org/archive/html/nano-devel/ If we want an editor in core beside "ed" at all is a different question. In the past there was a rule to get a basic but usable system up with base group and core repo (=cd iso image). Vi is still part of Posix standard: https://pubs.opengroup.org/onlinepubs/9699919799/ -Andy
On 2022-10-11 16:30:42 (+0200), Andreas Radke wrote:
How comes? Nano is actually pretty well maintained and has seen lots of updates over the past years. See
Yep, that's why I wrote, that it is at least still somewhat maintained (vi does not seem like it). :) My rationale would be, that text editors are not necessarily required for a working system and are rather basic tools (and one can argue endlessly which is the best hammer I guess :D).
If we want an editor in core beside "ed" at all is a different question.
Even ed is questionable, as it is only really required for `patch -e` (as optdepends) in [core] it seems. I have never seen a PKGBUILD make use of that.
In the past there was a rule to get a basic but usable system up with base group and core repo (=cd iso image).
On the installation medium we are able to define an arbitrary list of packages. For a long time the editor of choice seems to have been vim. Do you have a link to anything that was decided by the Arch Devs on the topic of what should be in [core] in the past? I guess I should have looked for that first, but I'm not aware of anything specific in the wiki at least. My rationale for slimming down [core] is to only have things in there that are required for running the most minimal Arch system and for building packages.
Vi is still part of Posix standard: https://pubs.opengroup.org/onlinepubs/9699919799/
However, [core] does not cover all of the POSIX Shell & Utilities (e.g. looking at batch, asa, bc, etc.). Are we even committed to cover POSIX Shell & Utility compat in [core]? Best, David -- https://sleepmap.de
In the past there was a rule to get a basic but usable system up with base group and core repo (=cd iso image).
On the installation medium we are able to define an arbitrary list of packages. For a long time the editor of choice seems to have been vim.
Do you have a link to anything that was decided by the Arch Devs on the topic of what should be in [core] in the past? I guess I should have looked for that first, but I'm not aware of anything specific in the wiki at least. Somewhere in the old mails there is probably something stated on how [core] was handled.
My rationale for slimming down [core] is to only have things in there that are required for running the most minimal Arch system and for building packages.
I don't think this is the right approach here. We should consider [core] will be the repository only devs will have full access, including the testing stage. Mission critical packages should be in [core]. Also it should give you a decent linux console system, with which you can handle your tasks . greetings tpowa -- Tobias Powalowski Arch Linux Developer & Package Maintainer (tpowa) https://www.archlinux.org tpowa@archlinux.org Archboot Developer https://bit.ly/archboot St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de info@st-martin-apo.de
On 10/11/22 12:05, David Runge wrote:
- preserve base-devel as a group there
I'm actually currently working on moving it to a meta-package as well. We didn't do it when introducing `base` as we never really changed it. Now we did with debugedit and face small inconveniences and we are better of to have it as meta-package as well.
- preserve base as a meta-package there - preserve makedepends and depends of a [core] package there
The checkdepends and also optdepends of a package may reside in other repositories.
makedepends doesn't actually matter, similar how checkdepends doesn't matter. Our builders always have the full repository set available (minus multilib). We only need to consider runtime depends. Cheers, Levente
On 2022-10-11 13:00:57 (+0200), Levente Polyak wrote:
I'm actually currently working on moving it to a meta-package as well. We didn't do it when introducing `base` as we never really changed it. Now we did with debugedit and face small inconveniences and we are better of to have it as meta-package as well.
Sounds good. While looking at base-devel I also noticed that e.g. fakeroot is in there, but it should actually be a dependency of pacman (as makepkg uses it) and opened a ticket for it [1].
makedepends doesn't actually matter, similar how checkdepends doesn't matter. Our builders always have the full repository set available (minus multilib). We only need to consider runtime depends.
Ah, that's an oversight on my part. All the better! Best, David [1] https://bugs.archlinux.org/task/76171 -- https://sleepmap.de
On 11/10/22 21:00, Levente Polyak wrote:
On 10/11/22 12:05, David Runge wrote:
- preserve base-devel as a group there
I'm actually currently working on moving it to a meta-package as well. We didn't do it when introducing `base` as we never really changed it. Now we did with debugedit and face small inconveniences and we are better of to have it as meta-package as well.
- preserve base as a meta-package there - preserve makedepends and depends of a [core] package there
The checkdepends and also optdepends of a package may reside in other repositories.
makedepends doesn't actually matter, similar how checkdepends doesn't matter. Our builders always have the full repository set available (minus multilib). We only need to consider runtime depends.
I would argue that makedepends and checkdepends do matter from a testing perspective. If we have [core] defined at essential packages to bootstrap a system, build time dependencies remain important and should go through testing. Of course that depends on our definition of [core]... I like the above definition, as it reflects the history of our distro starting from Linux From Scratch, and the build dependencies for things in [core] are fairly fundamental to things outside core too (e.g. meson) and deserve enforced [testing]. It also serves us well as more architectures happen - that would make [core] a self contained start point for bootstrapping an architecture. In summary, we need to define what it is we are trying to achieve with [core]. Allan
On 2022-10-12 11:29:52 (+1000), Allan McRae wrote:
On 11/10/22 21:00, Levente Polyak wrote:
On 10/11/22 12:05, David Runge wrote:
- preserve base-devel as a group there
makedepends doesn't actually matter, similar how checkdepends doesn't matter. Our builders always have the full repository set available (minus multilib). We only need to consider runtime depends.
I would argue that makedepends and checkdepends do matter from a testing perspective. If we have [core] defined at essential packages to bootstrap a system, build time dependencies remain important and should go through testing.
Of course that depends on our definition of [core]... I like the above definition, as it reflects the history of our distro starting from Linux From Scratch, and the build dependencies for things in [core] are fairly fundamental to things outside core too (e.g. meson) and deserve enforced [testing].
It also serves us well as more architectures happen - that would make [core] a self contained start point for bootstrapping an architecture.
If we look at it from a bootstrap perspective, then it would indeed be good to become self-contained in regards to makedepends and maybe also checkdepends (more overhead though). I agree, that this should encompass build tools used for the packages in core (such as meson) in the future in regards to "going through testing", but I would not want all the build tools in there (e.g. cmake, waf, scons, whathaveyou), if they are not required by packages in [core]. This breaks with the above base-devel assumption in case we ever want to add all the build tools to it. However adding build tools in general also drags in its own kitchen sink, and I understand why the rather small group of developers might not be fond of this.
In summary, we need to define what it is we are trying to achieve with [core].
Hm, we could create an RFC for evaluating and defining this better. It seems, that people have very different ideas and opinions about what should be in core and what not :) Maybe this would also provide a better overview to what proposed changes would actually mean in terms of added packages etc. Best, David -- https://sleepmap.de
I'm of the opinion that at least one well-maintained text editor should remain in core - my vote would be for nano, as vi has been outclassed by its clones and ed doesn't see much use nowadays. I have no personal issues with the other suggested cleanup items. Best, Campbell ------- Original Message ------- On Tuesday, October 11th, 2022 at 6:05 AM, David Runge <dave@sleepmap.de> wrote:
Hi all,
we need to do a bit of [core] repository cleanup.
In this MD [1] (publicly visible readonly link [2]) we have a list of packages that should leave [core], some maybes that need discussion before moving them and some that should be moved to [core] from the other repositories.
If you have more packages, that should not be in [core] anymore or should be moved to it, please add them to the list(s).
The general rules for inclusion in [core] are, that we want to - preserve base-devel as a group there - preserve base as a meta-package there - preserve makedepends and depends of a [core] package there
The checkdepends and also optdepends of a package may reside in other repositories.
As we have a few removals of packages in the list that concern packages only in [core] for historical (or other) reasons, please keep the discussion about them focused on technical reasons as to why they should potentially remain there.
Additionally, we have a few orphan packages in [core] that need adoption. Please adopt packages (if you can)!
Best, David
[1] https://md.archlinux.org/nrXL0ay5Tp6wP-f5M7N8bA# [2] https://md.archlinux.org/s/MliseALTG#
Am Tue, 11 Oct 2022 12:05:44 +0200 schrieb David Runge <dave@sleepmap.de>:
Hi all,
we need to do a bit of [core] repository cleanup.
Why do you think so? I can only imagine a cleanup where we need to drop a fully unmaintained and unneeded package to avoid security risks. And we may need to constantly replace obsolete packages with its successor e.g. mlocate->plocate. This should happen at any time without large lists and further heavy changes. -Andy
participants (6)
-
Allan McRae
-
Andreas Radke
-
arch＠serebit.com
-
David Runge
-
Levente Polyak
-
Tobias Powalowski