Arch Linux

zless is provided by this package, so to works properly it needs the less package.
Putting less in optdeps will make execution of zless, provided by this package fail to work with a not nice message:
/usr/bin/zless: line 50: less: command not found

Seeing that less is a base and expected package I don't see what we gain to remove that deps btw?

Suggest gzip upstream to move zless to less? xz have the same issue too.

>zless is provided by this package, so to works properly it needs the less package.
>Putting less in optdeps will make execution of zless, provided by this package fail to work with a not nice message:
>/usr/bin/zless: line 50: less: command not found

But zless is just an insignificant wrapper around less, along with a few other such wrappers in the same package. A user confronted with the error message could read zless(1) or type pacman -Qo zless followed by pacman -Qi gzip and would then see that less is required for zless. Zless is in my opinion somewhat like those {bash,zsh,powershell} completion files that come with some packages, they're more essential to the shell package than to the package they come with.

>Seeing that less is a base and expected package I don't see what we gain to remove that deps btw?

Is the base group not just a guideline for newbies who are installing the system? It includes many obviously rarely necessary packages like support for weird file systems and RAID. If you look through the mailing lists, you will find many people, including Archlinux contributors agree on that. Doug Newgard comes to mind.

What is gained is being able not to have less installed without fighting with Pacman.

Leave me out of this. Whatever you're referencing, my *opinion* is and always has been that base shouldn't be assumed, but currently is so you'd better know what the hell you're doing if you remove anything that's in it.

>Leave me out of this. ...

I am sorry about misrepresenting your opinion, I was mistaken. But I do not think that base is indeed assumed, or at least I don't know about any packages which assume base. I think what is usually assumed is Coreutils, maybe glibc and really basic stuff like that (along with base-devel for makedepends).

And in the case of less programs are usually smart enough to default to cat if less is not executable, or it is easy to fix.

...

But is this discussion about base not off topic? We should actually be discussing if gzip should depend on less...

Less is a dependency of gzip. That's not a bug. Moving it to optdeps would make part of the package broken and create a bug. I don't want to do that.

Note to mention that the benefit of having a system without less was not revealed (size, security, ...).

The xz package has no dependency on less, and nobody complains about it. zless/xzless are really just wrapper scripts, the package shouldn't have hard dependency on less.

We now have a "base" meta pkg instead of the old base group. While I do understand the sentiment behind the request, if this is implemented then anyone installing base won't get less, which for my 2 cents feels slightly retrograde.

If 'less' is important, then it should be added to the 'base' metapackage. But util-linux has 'more' for the same purpose, so I don't see this as a problem.

The question is not if less is important. It's a dependency because it's an unexpected behavior to zless do not have less installed.
What is your goal, have a system without less?

My main goal is to make packaging consintent. If xz (xzless) and zstd (zstdless) have no dependency on less, then gzip (zless) shoudn't have this dependency too. Or the other way: if gzip (zless) has dependency on less, then xz and zstd should have this dependency too.

The main purpose of gzip is to provide a command-line tool to handle .gz files. zless is just a wrapper script around less, a non-essential part of the package. Since 'less' is not part of the base group explicitely, removing this dependency would allow someone to have a system without 'less' installed.

ok, consistency makes sense with xz and zstd. They do not define optdeps neither.

xz is not an example of well defined dependencies... sh but not glibc.
The number of required deps for xz is a bit higher: grep, cmp, diff, cat...

I don't remember if we have a policy about what we should put in deps and optdeps.

It should be defined as optdepend in xz and zstd at least. So yeah, xz has some missing (opt)depends.

We have this policy about optional dependencies:
"Any optional dependencies that are not needed to run the package or have it generally function should not be included in the depends array; instead the information should be added to the optdepends array"
Source: https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette

And there is a recommendation:
"An array of packages that are not needed for the software to function, but provide additional features. This may imply that not all executables provided by a package will function without the respective optdepends. If the software works on multiple alternative dependencies, all of them can be listed here, instead of the depends array."
Source: https://wiki.archlinux.org/title/PKGBUILD#optdepends

So it's generally up to the maintainer to decide what is needed, and what can be considered as additional feature.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

A new version with less/more/diffutils as optdeps is in the repo.