Package review request: OpenBSD calendar(1) command

Toshio Kuratomi a.badger at gmail.com
Sun Feb 22 17:51:27 UTC 2009


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

Draft created here:
https://fedoraproject.org/wiki/PackagingDrafts/Common_package_names

I had to create the guideline that asks for common names to be changed
in addition to this exception to them :-).

Please check them out -- I tried to make the guideline that asks that
common package names be renamed sensible for the cases that do not fall
under the exception but may have missed the mark.  Comments are welcome.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090222/7062145f/attachment.sig>


More information about the fedora-devel-list mailing list