I've packaged up the calendar(1) command from OpenBSD and created a review request: https://bugzilla.redhat.com/show_bug.cgi?id=485853 Warren Togami reviewed it but raised an issue about the name of the actual command. The concern is that the name might be too generic and could possibly collide with something else. The executable is /usr/bin/calendar, as taken from OpenBSD. If you have any reservations about the executable being named /usr/bin/calendar, reply here or post in the review request.

>>>> "CW" == Christoph Wickert <christoph.wickert(a)googlemail.com&gt; writes:

Am Mittwoch, den 18.02.2009, 09:13 -0600 schrieb Jason L Tibbitts III: >>>>>> "CW" == Christoph Wickert <christoph.wickert(a)googlemail.com&gt; writes: > CW> Way to generic IMHO. If this is going to set a precedent, it will > CW> be hard to tell other maintainers, why /usr/bin/email [1] is a bad > CW> idea. > > Has /usr/bin/email been an expected part of many Unix systems for > twenty years as /usr/bin/calendar has? No, it hasn't. Maybe you are right and we could make an exception from the rules, but I think "this has been around for a long time" is not a good reason. If we followed that approach we could stop making changes at all.

I mean, "cat" is short for "concatenate" which some future concatenation utility may also wish to use. Not only is "concatenate" a very common word, "cat" is a very simple abbrevation which may clash with "catalog" or "categorize" - Shall we also change its name? Where does this stop? -Eric p.s. /usr/bin/the-utility-formerly-known-as-calendar does have a certain ring to it though I suppose.

No, it hasn't. Maybe you are right and we could make an exception from the rules, but I think "this has been around for a long time" is not a good reason.

Once upon a time, Christoph Wickert <christoph.wickert(a)googlemail.com&gt; said: > No, it hasn't. Maybe you are right and we could make an exception from > the rules, but I think "this has been around for a long time" is not a > good reason. Is there another program called "calendar" that this in causing a conflict with? How can it cause confusion when it is the only one?

Christoph Wickert wrote: > > What rule do we follow if another program comes up with the same name? > First come, first served? > In a large sense. Since calendar has been around for so long in the BSD world, it gets to keep the name.

If the other program was merely packaged for Fedora first, it would have to give up its name to the BSD calendar.

If there are two programs that don't have a long historical or standards-based claim to the name then we'd ask both packagers to approach upstream about renaming.

-Toshio

I've packaged up the calendar(1) command from OpenBSD and created a review request: https://bugzilla.redhat.com/show_bug.cgi?id=485853 Warren Togami reviewed it but raised an issue about the name of the actual command. The concern is that the name might be too generic and could possibly collide with something else. The executable is /usr/bin/calendar, as taken from OpenBSD. If you have any reservations about the executable being named /usr/bin/calendar, reply here or post in the review request.

> 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.

Once upon a time, Mathieu Bridon (bochecha) <bochecha(a)fedoraproject.org&gt; 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?

David Cantrell wrote: > Chris Adams wrote: >> Once upon a time, Mathieu Bridon (bochecha) >> <bochecha(a)fedoraproject.org&gt; 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. """

Toshio Kuratomi wrote: > David Cantrell wrote: >> Chris Adams wrote: >>> Once upon a time, Mathieu Bridon (bochecha) >>> <bochecha(a)fedoraproject.org&gt; 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.

> /usr/bin/calendar So who gets to decide what 'too generic' means ? We already have an even more generic command 'cal'.

No, it's defacto standard on BSDs for a very long. It's what *nix users expect to find as /usr/bin/calendar. Bluntly speaking: Forcing a renamer would be truely silly.

No idea why you want to refer to something irrelvant as V7. NetBSD, OpenBSD, FreeBSD all ship the same calendar(1): From their manpages: \" Copyright (c) 1989, 1990, 1993 .\" The Regents of the University of California. All rights reserved.

I've packaged up the calendar(1) command from OpenBSD and created a review request: https://bugzilla.redhat.com/show_bug.cgi?id=485853 Warren Togami reviewed it but raised an issue about the name of the actual command. The concern is that the name might be too generic and could possibly collide with something else. The executable is /usr/bin/calendar, as taken from OpenBSD. If you have any reservations about the executable being named /usr/bin/calendar, reply here or post in the review request.