FS#55635 - [glibc] Add optional dependencies for helper commands like locale-gen

Attached to Project: Arch Linux
Opened by Tinu Weber (ayekat) - Thursday, 14 September 2017, 12:31 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 14 September 2017, 18:54 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

glibc provides (among other things) the `locale-gen` command, which appears to depend on at least sed. This is not indicated anywhere, and thus the following bug reports were opened (and closed again), suggesting to add dependencies to glibc:

* https://bugs.archlinux.org/task/7184
* https://bugs.archlinux.org/task/25178
* https://bugs.archlinux.org/task/41294

The problem is that (A) a hard dependency would create circular dependencies and (B) glibc is perfectly capable of providing its core functionality (i.e. being a standard C library) without these packages.

However, its "helper" commands may still fail, so sed (and gzip?) should be added as *optional* dependencies (e.g. with "for locale-gen", the same way as it proposes gd with "for memusagestat").

(Also, before this gets closed as well with: "All packages in the 'base' group are supposed to be installed": The selection of packages in that group has repeatedly been questioned (the latest discussion being [1] and follow-up), and 'base' is by no means a "basic installation", but rather an "example basic setup, containg most of what you will likely need" - it's handy for newcomers, but not necessarily for users who would just like to pick the packages they really need)


Additional info:
* Package version: glibc-2.26-4

Steps to reproduce:
1. Install glibc as part of the installation procedure with `pacstrap`, without sed.
2. Run `locale-gen`.


[1]: https://lists.archlinux.org/pipermail/arch-dev-public/2017-September/028965.html
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Thursday, 14 September 2017, 18:54 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#7184   FS#25178   FS#41294 
Comment by Eli Schwartz (eschwartz) - Thursday, 14 September 2017, 18:53 GMT
We do not (yet?) have any policy about what to do with implicit depends on the base group. If and when we get such a policy, we will have to fix many, many packages, and we'll no doubt make a todo list to track them.
This assumes we don't end up making a base-system group which enforces an absolute policy of not depending on a minimal subset of packages.

For now it makes little sense to track one bug here and one bug there, when some packagers try to add all such dependencies and some packagers try to remove all such dependencies.

You know this perfectly well, as you explicitly referenced the current debate, and still opened a bug for something that is not currently a policy. Not only that, but the very first of those bugs *you* referenced, discussed and rejected the possibility of adding those as optdepends.
Please don't do this.

Loading...