Am 22. März 2017 21:56:57 MEZ schrieb "Bartłomiej Piotrowski" <bpiotrowski@archlinux.org>:

On 2017-03-22 21:51, Lex Black wrote:

...

Base and base-devel are a requirement for using the AUR and those packages shouldn't be added to the depends.

See the prerequisites on the AUR wiki page.

Well, no.

Someone who builds a package is expected to have base-devel installed. It does not apply to the base group. And worth noting, base-devel does not include base.

Bartłomiej

Ah, kinda on the wrong way. Dunno why I was thinking base-devel would include base. Thanks for the correction

On 03/22/2017 05:36 PM, NicoHood wrote:

On 03/22/2017 10:12 PM, Doug Newgard wrote:

...

On Wed, 22 Mar 2017 21:45:13 +0100 Baptiste Jonglez <baptiste@bitsofnetworks.org> wrote:

...

Am I missing something obvious?

Thanks, Baptiste

There's no specific rule about it. Some packagers will include packages in base in the depends, some won't. It's completely up to them.

You need to include base packages which are not in base-devel, as the package won't build without those sometimes. For example some packages detect systemd at build time and then adds its service files to the package. At least as makedepends they need to be specified.

I was also angry about this first, but this is actually a more clear way to build packages without unnecessary dependencies. Every user should build packages using devtools anyways to detect deps properly and to produce clean packages.

makedepends, maybe. Arch Linux does not support people who don't have systemd installed though, and regarding Baptiste's initial example of glibc, if you don't have glibc installed then your system is so screwed up it's not even funny... Given that the official instructions for installing Arch boils down to "install the base group into a blank partition and arrange a bootloader to boot that base group", I feel it is eminently reasonable to assume all valid Arch Linux systems have the base group installed... especially because some repo packages *are* built with implicit dependencies because of that exact logic. You really can't just go around uninstalling parts of base, or rather you can, but then it is up to you to know when your unsupported actions are likely to break something. (I say this with the full knowledge that I myself uninstall certain things I don't feel belong in base at all. I am willing to debug my own self-inflicted problems...) Though thinking about this, I actually wonder, maybe devtools should instruct you (rhet.) to install both base and base-devel into a build chroot... ... @Baptiste, The fact that namcap emits a warning, doesn't actually mean anything. :) namcap says/doesn't say a lot of things that are wrong, and all that *this* means is that namcap doesn't explicitly include code to filter out warnings for base packages. That could be because a) the namcap maintainer felt they should be dependencies anyway, or b) no one thought of it/decided to implement a filter, or c) both. namcap being what it is, I am 99.999999999999% sure it is either b or c. -- Eli Schwartz

On 03/22/2017 09:07 PM, beest wrote:

I'm also on the side of explicitly assuming that base is installed (and having the wiki and PKGBUILD dox reflect as much), but before that there should possibly be a discussion about what actually belongs in base in the first place. A few folks are of the mind that a good chunk of the group is wholly unnecessary and should be culled.

I will absolutely agree that there are additional packages in base that shouldn't be. I have brought this point up before a couple times.... Unfortunately, the maintainers of those packages seem to be entirely happy to leave them as-is, maybe on the assumption borne out in this thread that no one cares what is in base (except for silly things like the Installation Guide which no one cares about either, of course). Bizarrely, other package groups seem to have clearly-defined meanings which is strongly against the precedent set by the current base group... fsck/mkfs support for nonstandard filesystems - xfsprogs - reiserfsprogs - jfsutils Heavily discouraged by pretty much everyone, why on earth would it match any conceivable definition of "base"... - netctl :( Needed for device encryption/LVM/RAID, which not everyone uses - cryptsetup - lvm2 - device-mapper - mdadm No firm reason for including - s-nail (an inert mass unless you go out of your way to configure it) - nano (vi is the standard, and *I* don't even want to include that because vim) I would love for all these to be dropped from base, as I consider them neither recommended (Scimmia's concept of base IIRC) nor critical (the intuitive concept of base). Well, maybe the LVM/encryption stuff could be said to be recommended. But not critical. -- Eli Schwartz

On 03/23/2017 03:30 AM, Ralf Mardorf wrote:

On Wed, 22 Mar 2017 22:31:34 -0400, Eli Schwartz via aur-general wrote:

...

nano (vi is the standard, and *I* don't even want to include that because vim)

For modern Linux distros nano has become a standard as well. What's bad with providing it by base? Linux isn't UNIX from the 70s. Also, I'm not using reiser, but what is so problematic with including reiserfsprogs? It at least was a Linux FS preferred as default FS for e.g. Suse a few years back? It's idiotic to discuss such trivialities. Some prefer it more old school others less old school. You are more old school but that's not enough, you even want to discuss what belongs to the old school.

Because you are either an idiot or being deliberately unhelpful? You may not have realized, but the post you are replying to was arguing for a defined minimally bootable runnable operating system. What Suse used as a default FS is so completely irrelevant you should win an award... Also, stop discriminating against emacs and Atom, which by the same logic also belong in base because "stop being so old school". (I really didn't realize that there was *anyone* who considered the objectively horrible nano a standard. Almost any other editor ever, aside from MS Notepad, is better in every respect.... Did anyone else ever hear of this?) -- Eli Schwartz

On 2017-03-22 19:17 -0400 Eli Schwartz via aur-general wrote:

Given that the official instructions for installing Arch boils down to "install the base group into a blank partition and arrange a bootloader to boot that base group", I feel it is eminently reasonable to assume all valid Arch Linux systems have the base group installed... especially because some repo packages *are* built with implicit dependencies because of that exact logic. You really can't just go around uninstalling parts of base, or rather you can, but then it is up to you to know when your unsupported actions are likely to break something. (I say this with the full knowledge that I myself uninstall certain things I don't feel belong in base at all. I am willing to debug my own self-inflicted problems...)

Though thinking about this, I actually wonder, maybe devtools should instruct you (rhet.) to install both base and base-devel into a build chroot...

On 2017-03-22 21:07 -0400 beest wrote:

I'm also on the side of explicitly assuming that base is installed (and having the wiki and PKGBUILD dox reflect as much), but before that there should possibly be a discussion about what actually belongs in base in the first place. A few folks are of the mind that a good chunk of the group is wholly unnecessary and should be culled.

The PKGBUILD should specify all necessary information for full dependency resolution without assuming anything other than base-devel*. Extending the assumption to the full base group just so some packagers can avoid typing a few extra words *once* when they create the PKGBUILD is just laziness. It's not even a real burden given that most deps are pulled in indirectly by other deps so at most you usually only need to list a few. If a PKGBUILD does not contain all information for full dependency resolution (minus base-devel), then it is technically incorrect (it lacks required metadata). There is no "base installation" of Arch Linux. That's one of the defining features of this distro. Forcing some people to install bloat and cruft (or play dependency spelunker) to save a few keystrokes in a PKGBUILD is just wrong. It also fails to consider use cases such as minimalist chroots for building packages. Regards, Xyne * I could even argue that makepkg should check for base-devel and include it in dependency resolution automatically with the --syncdeps option.

Well, it also means, for example, that you don't have to keep listing things like bash and glibc in literally hundreds of PKGBUILDs.

I understand that argument, but it is framed as if people are writing hundreds of PKGBUILDs at once and the added deps are overly tedious to include, when in fact they are written one at a time and it's only a few extra words (at most) alongside however many constitute the PKGBUILD. For makedeps, most of these are not even needed because they are indirect deps of base-devel. All runtime deps should be resolved though, either directly or indirectly. The only valid technical argument would be if the overhead of the dependency checks is prohibitive. I expect that it is negligible (but admittedly haven't checked) and it is worth technical correctness. It's like quoting path variables in PKGBUILDs: most people build in "sane" paths but it's still poor form to omit the quotes and assume that no one builds on paths with spaces. The arguments "but I don't want to type more quotes" and "but all those quotes across all the PKGBUILDs take so many bytes" are rightly rejected.

...

There is no "base installation" of Arch Linux. That's one of the defining features of this distro. Forcing some people to install bloat and cruft (or play dependency spelunker) to save a few keystrokes in a PKGBUILD is just wrong.

There absolutely is a base installation. Unless you are suggesting e.g. systemd-less systems constitute a supported Arch Linux installation?

This isn't about what is officially "supported". This is about how one tool performs a task. Arch provides flexibility. There are custom kernels and alternative init systems in the AUR for example. If you customize your system then you are expected to deal with problems arising from that customization yourself, but core functionality of the package manager should not rely on all users installing essentially the same base system. We are talking about dependency resolution here. Pacman is not tied to systemd or whatever else you consider to be part of a "base installation". It shouldn't even matter what other packages the user is using as long as pacman's own deps are satisfied. For dependency resolution, Pacman's job is to determine what the user wants to install and then figure out what else the user needs to install it. All it needs to do that is the correct metadata, which is just a few extra words in some text files. That is better than implicit assumptions that may silently change in the future.

I thought that was the point of suggesting that minimalist build chroots potentially require base as well...

A chroot that requires all of the base group is not minimal, it's bloated. It's like a lazy fruit vendor dumping apples, oranges, bananas, etc. into one giant bin because he can't be bothered to put them in separate bins (even though he has them, and it would be simple to do), then forcing customers who only want apples to buy big boxes of mixed fruit so that they can sort out the apples themselves and throw the rest of the fruit away (after paying for it). Regards, Xyne

On 2017-03-23 09:32 -0400 Eli Schwartz via aur-general wrote:

And a system that does not have glibc installed is not a valid use-case. A system without bash is not a valid use-case. A system without systemd is not a valid use-case, regardless of how many completely-unsupported people kludge it together with AUR packages (which also are unsupported).

Obviously there has to be a system for a package to be installed on and that system has a finite number of necessary components that will always be present. If that's what the base group was, then we would likely be in agreement. As it stands now, a python module, for example, doesn't need nano, systemd, lvm, tar, vi, etc. As for valid use-cases, minimal chroots are one. I'm not going to argue for the others.

I don't have actual numbers for the dependency checking time... but it is surely nonzero, and I see no reason to go out of my way to add them purely for the sake of slowing down pacman's depchecks to whatever degree, adding PKGBUILD code churn and decreasing clarity by cluttering it with obvious no-brainers, given that the result is still lacking in technical correctness, since *technically*, a binary that only links to glibc still needs a lot of other stuff like a working system running a linux kernel to run.

glibc seems to be your go-to example but it's not the best example. Loads of packages depend on it already. Should all of those deps be removed? Should you really be able to uninstall glibc without pacman complaining about broken deps? A binary that links against glibc should directly depend on it imo. A bash script should depend only on bash. Same for other scripts and their respective interpreters. The remarks about a working system are conflating two distinct concepts. A system is needed to run code in the first place. That's a given. Once you get that code running, it in turn directly runs other code or uses other data. That is a dependency in the sense of package management. The infrastructure for running the code is not. That's a meta-dependency. If you want to compare the two, you may as well throw in hardware specs. Those are also equally necessary but it's a different type of dependency.

Redefining dependencies as shared library linkages would make this a more compelling argument.

Agreed.

Really, if you want technical correctness, then I expect to be able to pacstrap any single package into an empty partition/directory and have pacman resolve dependencies to a sufficient degree to result in a bootable/chrootable minimal installation in which that package functions as expected.

Pacstrap *should* install everything necessary for a chrootable system (minus whatever mountbinds the host system has do provide). A bootable system is a different matter. In the chroot case, you want to run foo (foo is the primary target). In the bootable case, you want to boot a system, and then run foo (so the system is the primary target).

Arch is *not* about choice or flexibility, not when it comes to the base system itself. This is a rather emphatic aspect of the Arch Way. After several complaints from users about systemd specifically, this *had* to be emphatically clarified.

From the current "Arch Linux" wiki page:

The default installation is a minimal base system, configured by the user to only add what is purposely required.

It is still up to the user to decide which packages to install even if base is recommended. If you don't use nano or lvm, there is no need to install those packages, for example. Getting rid of systemd is far more complex due to its centrality in the package ecosystem, but there are nevertheless plenty of packages that happily run without systemd and thus systemd is not a direct dependency.

Right... I never suggested that pacman itself enforce a base installation and I have no idea how you think I would go about doing that anyway.

The whole discussion is about whether or not the base group should be installed by default or at least assumed to be installed. If packages will not work because dependency resolution fails in the absence of unspecified base packages, then you are essentially forcing the user to install the full base group (or manually resolve deps after noticing that a package doesn't work).

People using pacman as a package manager for, say, LFS or MSYS2 are more than free to provide whatever installation instructions they want, and make whatever implicit assumptions they like regarding a base installation, and declare a PKGBUILD style policy suiting those assumptions.

Arch Linux is allowed to have different assumptions than pacman and makepkg (and base-devel is an example of that).

Sure. Pacman could assume that the full base group is installed. It could even assume that all of core is installed. It doesn't need to assume that though. I think it's better if it makes no assumptions as we can easily provide the information explicitly. If you can identify a minimal group of packages that are required for any given package to run in all use cases, then that would be a reasonable assumption that could be omitted from explicit deps.

The same logic applies to base-devel, most of which will not be used in any given build. In fact, there are plenty of PKGBUILDs which use nothing other than a package() function with calls to mkdir/cp/install.

Yep. I think makedeps should be explicit too and I stated so in a previous reply. I'm not arguing for that here though. Also, base-devel is a little different in that it is assumed for building packages, not running them. You don't need to keep it on your system to ensure dependency resolution when installing packages.

TIL, Arch Linux is bloated and lazy. o_O

If you require users to install packages that they will never use and technically don't require in order to be able to use the system normally, then that is bloat. If you do so because you don't want to type a few extra words, then that is indeed lazy. No need for sarcasm btw.

On Sat, Mar 25, 2017 at 09:19:43 +0100, Ralf Mardorf wrote:

On Sat, 25 Mar 2017 06:47:07 +0000, Xyne wrote:

...

A bash script should depend only on bash.

Hi Xyne,

Seems to be better it would depend on coreutilsor do you asume a bash script only depends on bash intern commands and woun't use external commands such as e.g. basename?

In such a case, yes, the application should state that it depends on coreutils. I don't see an issue, though, other than "I don't want to type that".

...

It is still up to the user to decide which packages to install even if base is recommended. If you don't use nano or lvm, there is no need to install those packages, for example.

A user always is allowed to customize the install. On my install are even some hard dependencies missing, but on another software level, not on the base level. The Arch community needs to share some base system. If we wouldn't, we wouldn't need Arch related mailing lists. There must be something in common to call Arch "Arch".

I don't think that the Arch community or the OS itself is solely defined by an arbitrarily selected set of packages that are expected to be installed. After all, the systems still share the package manager and the origin of the packages (created and provided by Arch devs) + the general idea of KISS (e.g. upstream as unpatched as possible, no partial upgrade support, ...) I think some people are mixing up these two things: 1. Packages that are expected to be there to guarantee a minimally working system in most situations. 2. Packages that are expected to be there to provide a minimally comfortable working environment to the user. I could live with the group 1 being mandatory (I wouldn't be happy, but I could accept it). But not group 2, because at that point, things get a little more subjective. Let me quote the Arch Wiki article on Arch Linux:

VERSATILITY:

Arch Linux is a general-purpose distribution. Upon installation, only a command-line environment is provided: rather than tearing out unneeded and unwanted packages, the user is offered the ability to build a custom system by choosing among thousands of high-quality packages provided in the official repositories for the x86-64 architecture.

I'm sorry, but I currently find myself "tearing out unneeded and unwanted packages". And in a sort of a "killing spree", I find myself removing packages from both groups 1 and 2 as defined above. I end up with something like my personal little VPS, for instance: * I won't plug in any USB devices or PCMCIA cards (usbutils, pcmciautils) * I use systemd-networkd for my static network configuration (netctl, dhcpcd) * I don't use LVM or block-level encryption (lvm2, cryptsetup) * Being on a VPS, I don't care about RAID (mdadm) * I don't intend to interact with any other file systems than ext4 (jfsutils, reiserfsprogs, xfsprogs) * I don't use nano (nano) * I use zsh as my interactive shell, and generally write my shell scripts in POSIX sh, for which I have dash installed (and linked sh to), so bash is installed --asdeps. * I don't use any of the tools in ineutils, so it's installed --asdeps. * I still keep the "normal" Linux kernel around "just in case" - but really I am booting the LTS kernel. Now, is that no longer Arch Linux? I would say Yes. But with the current policy, it appears that No. Not because I'm running unsupported software, but because I just got rid of a few things that I don't need. Same goes for my laptop setup (although for a smaller set of missing packages there). Or my little test container, where I don't need the kernel, for instance. I do not oppose the idea of having a group of packages that are *recommended* to be installed - people who don't quite know what they need can just install that group and assume that they will probably not run into too much trouble. But people shouldn't be *forced* to install those packages (or find themselves in the "not supported here!" zone).

...

The whole discussion is about whether or not the base group should be installed by default or at least assumed to be installed. If packages will not work because dependency resolution fails in the absence of unspecified base packages, then you are essentially forcing the user to install the full base group (or manually resolve deps after noticing that a package doesn't work).

Correct. What's wrong with this approach? You safely could remove nano, to free the immens amount of disc space it takes. Others, e.g. Eli seemingly do this. Unlikely a package explicitly will have a hard dependency on nano.

[rocketmouse@archlinux ~]$ pactree -r nano nano

I find a little irony in the fact that you use to pactree/pacman to show that nothing depends on nano, when the issue here is exactly that pactree/pacman becomes unreliable for packages in base.

Just in case a package really should depend on nano, then the user needs to reinstall it. I expect a user who decides to remove packages from "base" to understand what she's doing. There are valid reasons that base does include a few packages, such as nano, even if those are not necessarily required or fit to UNIX standards from the 70s.

Yes, those are valid assumptions for a "base install" as in "before the user starts configuring their system to their needs". And I'm happy that there is at least one text editor in that "base install". But once I'm done and have switched to vim or emacs or atom or whatever else I happen to use, I might feel different about that. (Just to clarify, I don't get all this hate on nano. It's a fine editor for people who just want to quickly edit something from a non-graphical environment and don't want to be bothered learning the quirks of vi or emacs.) Of course, nano is tiny, and there is no harm in keeping it around. But together with all the other packages we don't need, it starts feeling like clutter. Especially if I have to mentally filter out those packages from the output of `checkupdates` before I decide whether I want to run that update, or leave it because it only affects packages I don't use. Best, Tinu

I think we should encourage packagers to name *all* their depends and makedepends, even if they're in base{,-devel}. Not require (yet) but encourage. My problem with this whole discussion is there's no hard data. There's no clear empirical process for deciding what should be in base{,-devel}. We only have a circular process: packages shouldn't be removed because that might break some PKGBUILDs, and PKGBUILDs continue to omit dependencies because they're implied. And meanwhile the conversation devolves into bikeshedding about the virtues of nano, etc. The only way to break out of this cycle is for packages to start explicitly naming dependencies. If you have shell scripts, depend on sh. If you need bash-isms, depend on bash. If you're a daemon with systemd units, depend on systemd. If you build with git or glibc, makedepend on those. Once this happens we can inform our arguments with actual numbers.

On 2017-03-25 16:31 +0100 Tinu Weber wrote:

On Sat, Mar 25, 2017 at 09:19:43 +0100, Ralf Mardorf wrote:

...

On Sat, 25 Mar 2017 06:47:07 +0000, Xyne wrote:

...

A bash script should depend only on bash.

Hi Xyne,

Seems to be better it would depend on coreutilsor do you asume a bash script only depends on bash intern commands and woun't use external commands such as e.g. basename?

In such a case, yes, the application should state that it depends on coreutils. I don't see an issue, though, other than "I don't want to type that".

I was going to say the same thing before I saw Tinu's reply. My example of a bash script was bad given that most bash scripts will indeed depend on coreutils. coreutils is one of the packages that I think should be assumed in a minimal system btw.

...

...

It is still up to the user to decide which packages to install even if base is recommended. If you don't use nano or lvm, there is no need to install those packages, for example.

A user always is allowed to customize the install. On my install are even some hard dependencies missing, but on another software level, not on the base level. The Arch community needs to share some base system. If we wouldn't, we wouldn't need Arch related mailing lists. There must be something in common to call Arch "Arch".

I don't think that the Arch community or the OS itself is solely defined by an arbitrarily selected set of packages that are expected to be installed. After all, the systems still share the package manager and the origin of the packages (created and provided by Arch devs) + the general idea of KISS (e.g. upstream as unpatched as possible, no partial upgrade support, ...)

I think some people are mixing up these two things:

1. Packages that are expected to be there to guarantee a minimally working system in most situations. 2. Packages that are expected to be there to provide a minimally comfortable working environment to the user.

I agree that people are mixing up two things but I would say that they are 1. Dependency resolution. 2. What constitutes a minimal Arch Linux system. The second is arbitrary. There is no obvious definition, and it doesn't even matter with regard to the first. Explicitly providing the necessary metadata will always work and makes no assumptions. This will benefit all users but forces a few packages to type a few extra words. Assuming (and thereby effectively requiring) that an arbitrary set of packages are installed, even when many of those are unneeded, is a philosophical wart for a minimalist distro that leads to wasted bandwidth and disk space, or broken dependency resolution in some common use-cases. I am actually surprised that there is even an argument for requiring a base system with packages that many users will never need (and the whole "but anyone 'competent' enough to remove some of those packages can manage their own deps manually" is not a valid argument: the distro should not make things more difficult for users who remove unneeded packages). I get that things change, but it's sad to see people pushing Arch in that direction. Minimalism is one of Arch's defining features imo. If packagers do their job (provide package metadata), then pacman can do its job (dep resolution). It's really that simple. If you absolutely want a minimal common group with e.g. glibc, coreutils, linux and whatever else is effectively indispensable, then ok. Even then those packages should be resolved by pacman/makepkg. Regards, Xyne

On Thu, 2017-03-23 at 01:38 +0000, Giancarlo Razzolini wrote:

Em março 22, 2017 18:12 Doug Newgard escreveu:

...

There's no specific rule about it. Some packagers will include packages in base in the depends, some won't. It's completely up to them.

But, if at least the maintainers built their packages using a clean chroot, they would know what they are missing from base to include on depends. I don't think we need to enforce that rule to the AUR, but it is a rule for repo packages for a good reason. We could, however, suggest on the wiki, if it isn't already, that even for the AUR, the *maintainers* build their packages using devtools.

Cheers, Giancarlo Razzolini

Doesn't the standard chroot end up with all of base and base-devel or is that not currently the case?

On 03/22/2017 10:02 PM, Daniel Micay via aur-general wrote:

Doesn't the standard chroot end up with all of base and base-devel or is that not currently the case?

The "standard chroot" is a help message in makechrootpkg saying ``` The chroot "root" directory must be created via the following command: mkarchroot <chrootdir>/root base-devel ``` and corresponding automation in archbuild. mkarchroot is really just a btrfs/CHROOT_VERSION wrapper around pacstrap... As I said earlier, perhaps this is something that could/should be rethought? -- Eli Schwartz

Le 29 mars 2017 00:32:09 GMT-07:00, Baptiste Jonglez <baptiste@bitsofnetworks.org> a écrit :

So, I didn't think such a technical question would spark so much passion! Maybe this discussion should indeed go to arch-dev-public.

Probably, since this is not just discussing the AUR policy but packaging at the whole scale.

In the meantime, I see 4 positions emerge from the discussion:

1) packages in "base" *should* be explicitely listed as dependencies (either for mere "technical correctness", or because of bloat, i.e. not everyone wants/needs all packages from "base")

That’s what I’m in favour of, but there is another option you’ve forgot about that could potentially suits me as well (see below).

2) packages in "base" *should not* be listed as dependencies (because it is assumed that all Arch Linux systems have all packages from "base" already installed)

Most of my installs consist of only few base packages installed as explicit, and probably half of base packages not being installed at all. I expect that to be a valid install, and I indeed don’t like bloat.

3) it depends on the maintainer (i.e. there are no guidelines on this question)

4) it depends on the base package in question (e.g. it would be acceptable to depend on glibc, but not on systemd)

I get the impression that 3) is the current status quo. I find 4) to be quite strange and subjective, but it could be done (e.g. only allow library dependency such as glibc, or allow all dependencies except a few like systemd).

I have two more arguments in favour of 1) or 4), related to technical correctness:

- when a new version of glibc is released, which packages should be rebuilt? Without complete dependency information, I don't see how it's possible to know.

I think that TODO for rebuilding are determined by looking at ldd output, or at least they could. But I would not make that an argument for removing glibc from depends, it will anyway be indirectly depended on for most packages.

- Assume that all "base" packages are supposed to already be installed, and thus no other package depends on "base" packages. When a new package X is added to "base", how is an already-running system supposed to pick it up if no dependency pulls it in?

Which is a very good argument. Also, from the discussion there is 2.b) option, which consist in additionaly redefining base (and potentially base-devel as well, but let’s keep this separated) to really only consist of the minimal core system (maybe something in the like of pacman, glibc, systemd, linux, a shell, UNIX tools, and their dependencies). But maybe that definition of base would already be controversial/to subjective in which case we’re back to 1) being the only correct solution I would say. Bruno

On 03/29, LoneVVolf wrote:

It looks like many here haven't looked at base group in a while, or don't distinguish between base group and core repository.

example : systemd-sysvcompat is in base, systemd is NOT . Both are in core repo .

LW

systemd-sysvcompat depends on systemd (obviously), thus systemd is effectively part of the base group. So I don't really get your point? -- PGP ID: 0xC8F0B2F4