Upstream util-linux provides a cal binary, that is, in my opinion, superior to
the cal provided by the ncal package, since the output is much more flexible.

With the current cal provided ncal package the switches to configure the start
of the week or week numbers are only available with the ncal binary, but not the
cal binary.

The util-linux version of cal provides a unified interface, including a vertical
display like ncal, in a single binary. Unfortunately the command line switches
are not compatible and util-linux cal cannot display the date of Easter, so it
is not drop-in compatible. It would nevertheless be great if e.g. an
alternatives selection for util-linux cal could be provided.

Hello,

* Jörg Behrmann <behrmann@physik.fu-berlin.de> [240503 16:39]:
[..]

I'm somewhat open to shipping util-linux's cal, but not if that
involves update-alternatives.

Could you maybe work with upstream, so that util-linux's cal becomes
a drop-in replacement, and can work as both cal and ncal?

Also, quite obviously is this something we want to do as Debian?
Michael, as the maintainer of the current ncal package, what is your
opinion here?

Chris

I think that ship has sailed already, since e.g. -m in the ncal version
specifies the month (a bit superfluously), whereas in the util-linux version it
sets the beginning of the week to Monday.

An alternative I could see would be to drop cal from the ncal package and only
provide cal from util-linux.

Nothing would be lost, since ncal can act as cal with the -C option, so users
wanting that specific cal could use a function

    cal() {
        ncal -C $@
    }

and the rest would get a cal that can show week numbers and set the beginning of
the Monday.

The question is does it offer all the other features? Or would we be
better of switching to something like gcal instead?

Agreed.

I wouldn't mind getting rid of the old bsd code base. The package is
heavily patched, which makes maintaining it a lot of work. I would not
like to lose too many features, though. The main reason for keeping
cal, however, namely having a version fully output compatible to the
original one, might not be that valid anymore. After all it's 2024
already.

Michael

Not sure why specifying the month is superfluous.

Now I'm confused. Is the reason for this proposal to have a cal that
shows week numbers and forces the start of the week to Monday? Well,
ncal does both of this, so why don't you just use something like "ncal
-wMb" as cal? Not that ncal needs "-M", it is able to get this from
your locale.

Michael

I'm sorry, that was a bit tongue in cheek. I'm sure there are valid uses for
this, but since cal can take the month as first argument, when given two
numeric arguments, there are multiple ways of achieving the same goal.

The example was to show how people could achieve using ncal to get cal, if the
ncal package would not ship a cal binary.

This is *not* about forcing Monday, util-linux cal takes that from the locale as
well, but when working in mixed locale settings or on a machine with just
C.UTF-8, it is nice to be able to change it and the obvious "cal -M" fails for
the ncal version, as does "cal -w". Requiring the use of ncal (instead of cal)
and an option documented as "Use oldstyle format for ncal output" seems highly
non-obvious to me.

That depends on what all the necessary features are? The differences as far as I
can see them at this moment are

- util-linux cal doesn't provide the date of Easter, unlike ncal cal
- util-linux cal supports beginning of week and week number switches for cal,
  which do not work with ncal cal
- util-linux cal supports years after 9999
- util-linux cal supports month names as strings instead of the -m argument
- ncal cal has -B and -A arguments for before and after, util-linux cal has a
  --months (-n) switch for the number of months and they can be cented around a
  given month with the --span (-S) option

gcal supports more different calendars and more holidays, but this seems to go
beyond the basic calendar functionality of either util-linux' and ncal's
implementation.

Sure, but the only reason for the cal binary as it is, is to have the
original cal available. All new and extended features are in ncal and
are explicitly deactivated when called as cal.
cal mode. For cal like output only, use  -b  instead.

But anyway, there is a reason behind cal offering only the features it
does. If you want all the additional bells and whistles you're free to
alias cal to ncal for your system.

But it is supported in ncal. Again, think of cal as traditional-cal if
that makes it easier.

Michael

That is valid reasoning or was at some point, but I want to argue that it might
be good to rethink it today, since Alpine [1], Arch [2], CentOS [3], Fedora [4],
Gentoo [5], Mageia [6], OpenMandriva [7], OpenSuse [8], RHEL [9], and Slackware
[10] ship the /usr/bin/cal binary from the util-linux package (or split version
of the package in case of Alpine or they don't disable it by default in the case
of Gentoo). This is true even for very BSD forward Linux distributions like
OpenMandriva.

My point is, that anybody not using Debian or a derivative will expect cal to be
the util-linux version.

I will continue to think of ncal as the weird column-order calendar. :)

In more seriousness, if the expectation is for people to use ncal and cal is
just a remnant, that should best be ignored, I'd prefer that difference to the
rest of the Linux distribution ecosystem be whittled away instead.

[1] https://alpine.pkgs.org/3.19/alpine-main-x86_64/util-linux-2.39.3-r0.apk.html
[2] https://archlinux.pkgs.org/rolling/archlinux-core-x86_64/util-linux-2.40-3-x86_64.pkg.tar.zst.html
[3] https://centos.pkgs.org/9-stream/centos-baseos-x86_64/util-linux-2.37.4-18.el9.x86_64.rpm.html
[4] https://fedora.pkgs.org/40/fedora-x86_64/util-linux-2.40-0.9.rc1.fc40.i686.rpm.html
[5] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/util-linux/util-linux-2.39.4.ebuild
[6] https://mageia.pkgs.org/cauldron/mageia-core-release-x86_64/util-linux-2.40-3.mga10.x86_64.rpm.html
[7] https://openmandriva.pkgs.org/rolling/openmandriva-main-release-aarch64/util-linux-2.39.4-1-omv2490.aarch64.rpm.html
[8] https://opensuse.pkgs.org/tumbleweed/opensuse-oss-x86_64/util-linux-2.39.3-4.2.x86_64.rpm.html
[9] by virtue of CentOS
[10] https://slackware.pkgs.org/current/slackware-x86_64/util-linux-2.40-x86_64-2.txz.html