Re: Is base group an implicit optional dependency?

Yes, but doesn't seem to apply to packaging. For example, coreutils is supposed to have no dependencies at all but it has a crazily detailed `pactree`. Even `pacstrap /mnt systemd` produces surprisingly working rootfs, so it seems many people care about dependencies on `base`.

So the rule of ignoring `base` in certain cases, if it exists, should be more detailed and worth documenting.

However, a short google query for "arch linux base group dependency" brought up this:

Note: Before complaining about missing (make) dependencies, remember that the base group is assumed to be installed on all Arch Linux systems. The group "base-devel" is assumed to be installed when building with makepkg.

Re: Is base group an implicit optional dependency?

Your google-fu is better than mine

It doesn't seem that "no dependency on base" policy is followed closely. I wonder if there are any packages which don't specify dependencies on `base` explicitly. And `napcap` complains if deps on base exist but not specified.

Should I made the policy explicit by editing wiki and adding "no deps on base" everywhere "no makedeps on base-devel" is specified? I think such policy applied to packages in `base` will break everything.

On the other hand, is "we don't care but you can omit deps on base should you wish" an acceptable packaging policy?

Re: Is base group an implicit optional dependency?

On the other hand, is "we don't care but you can omit deps on base should you wish" an acceptable packaging policy?

I'm pretty sure this is the de facto standard. You shouldn't run into anyone who freaks out on you b/c you did or didn't include glibc, bash, etc.

"Install base-devel before using makepkg" has been in the wiki for years, but people will keep flagging your packages out of date and post comments like "needed pkgconfig to build, please add to makedepends." Sometimes I'll just include some base-devel makedeps just to deal with less hassle..

Re: Is base group an implicit optional dependency?

nponeccop wrote:

On the other hand, is "we don't care but you can omit deps on base should you wish" an acceptable packaging policy?

I think it is time to ask this on the mailing list. While Allan can be seen here very often, you have a higher chance of success there, where other package maintainers read more vigilantly. But ultimately, I think you are just over-complicating the issue.

Basically, you, as a user, do not create packages for Arch, so your only concern might be the AUR. I would, with no doubt, add every single relevant ("first level") dependency to any PKGBUILD I upload, no matter where the package is. The same is the case for all the packages in all the repositories, if the absence of X would break Y, add X to the deps. Then again, the base group is assumed to be installed on every Arch system (although the current installer allows a more fine-tuned setup), so if a package is missing a dependency in the base group, it is not considered to be a big deal. It does not mean, that such a package should not be added to the deps, it just means, that you are not supposed to create a bug report just for that, because every bug report means valuable time going down the river.

We could now start to argue, that the current Arch installer allows for a base group free Arch without removing a single package post-install. This would mean, that the presence of the entire base group can no longer be assumed and adding the dependencies in base would suddenly make more sense. Discussing this here, on the other hand, instead of the appropriate mailing list, would not.

Re: Is base group an implicit optional dependency?

A related question may be how static are base / base-devel group memberships. In otherwords, do packages occasionally get added or removed from these groups?

Packages occasionally move from the aur to [community] and other occasionally drop from any of the repos to aur ... or to pergatory. If base/base-devel package lists occasionally change, one might write a PKGBUILD not listing a dependency because it is part of base, only to have it later dropped from base; or vice versa.