Toshio Kuratomi wrote:
David Cantrell wrote:
Chris Adams wrote:
Once upon a time, Mathieu Bridon (bochecha)
<bochecha@xxxxxxxxxxxxxxxxx> said:
If name clashing is a real problem
then the upstream project should decide how/what to rename it too.
Of course upstream should decide and the review requester is
supposed to
bring this problem up there.
This looks to me like the "sendmail" command. Isn't it a rather
generic name for a command ?
But it can be provided by several packages, and we use the
alternatives system for that.
Couldn't we do the same for calendar ?
Is this "calendar" the same as:
calendar - Writes reminder messages to standard output
If so, that is the program name, and it should stay. I've got it on
Tru64 Unix (which is BSD derived from many years ago) as a standard part
of the OS.
Is somebody next going to say "ed" has to be renamed because there are
other editors?
Yes, this is the calendar command you are thinking of. It prints
reminder messages and can easily be dropped in to cron. It's been a
standard part of BSD for quite some time, but Linux has lacked an
equivalent.
I have taken this command from the OpenBSD source repository and patched
it for Linux. So, upstream for this command is not going to change the
name (as suggested by some other people).
The name of the program has always been 'calendar'.
So AFAICS there's currently no Guideline that specifies maintainers MUST
be proactive about conflicts. I've been proactive about conflicts when
there were other Unix programs out there as that's common sense. But
when the program in question is a standard command then common sense
would be that the program should not be renamed... anything else that
conflicted with this would either be trampling on the standard command
and should be renamed or a reimplementation of the standard command that
should be provided via some alternatives-ish mechanism or deciding one
has better features and dropping the other.
So what is a "standard command" is the crux. If we had a Guideline I'd
be inclined to have something like this:
"""
Common names are allowed for standard commands since those will be the
only commands to implement them. Standard commands include things
provided for in published and widely implemented standards like POSIX
and de facto standards such as a program that has traditionally been
shipped with a certain filename as part of a large number of Unix
variants. If in doubt, send a message with details of what standards
the command appears in, how long it's been available on what Unix
systems, and whether you've found any conflicting programs that
implement a substantially different command with the same filename.
"""
I believe the above text is a good addition to the Packaging Guidelines.
calendar(1) has been around for a very long time and has always been
called calendar. It's so common that many people even consider it a
standard command on Unix systems. The man page states in the HISTORY
section:
A calendar command appeared in Version 7 AT&T UNIX.
So anything derived from that release had the opportunity to carry
forward the calendar command[1]. Of the BSD systems I've used (Free,
Open, Net, Up, Down, Left, Right, SunOS, others...), it appears that
they all have carried forward the calendar command and kept it named as
'calendar'.
My argument in favor of keeping it named 'calendar' is not simply
because that's the way it's always been, but because I think it's a
command that is part of a well defined set of Unix commands. Things
like ls, cp, cat, and so on. calendar is another one of those commands.
The many HOWTOs, tutorials, books, and other training materials that
show people how to use calendar would be lost on Fedora users if we
renamed the executable.
So, shall it stay named 'calendar' and be added to Fedora?
[1] http://www.levenez.com/unix/unix.pdf
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
