Naming problem for the "Falcon Programming Language" in Ubuntu.

Giancarlo Niccolai gc at
Mon Jan 14 00:55:22 GMT 2008

Hash: SHA1


I'd like to report a problem that is concerning the naming of two
packages that are being concurrently racing for inclusion in the very
next version of Ubuntu.

I would argue that the way MOTU have managed the whole situation is
questionable under the "Ubuntu Code of Conduct" that we all have signed.

I came to Ubuntu as I wanted to issue my first official release of the
Falcon Programming Language

under the distro which I most respect, for its philosophy of mutual
help and support which is reflected in the Code of Conduct. The very
heart of my project is exactly "Respect for Developers", which drove
my will to write a language written not "to parse logs" or "to keep
finger warm", but exactly to help people write better programs, and to
help applications to be better applications.

When I prospected my project in #ubuntu-motu I have been positively
accepted by the community; so I started writing a module; I searched
Debian and Ubuntu repositories, and the net in search of debian
packages named Falcon. Having not found them, I went for "falcon" as
package name. People in MOTU told me that the naming of the package
was fine, although some of them knew of a packaging utility written in
python that was called "". I offered to change the name of
the package to falconpl, that was also the name of the site, but I
have been told (sorry if I call people by nick), by pochu, persia and
others that the name was ok, and to proceed. I have talked also with
Minghua and many others.

So I uploaded the package on December 6 2007 in Revu. I got comments
through #ubuntu-motu channel, and I updated each time to fix problems
reported by MOTU reviewers. The records are in

On December the 20th 2007, a Motu (possibly Imbradon, but I am not
sure), told me that the project called "falcon" had possibly a
/usr/bin/falcon instance, which the Falcon programming language has
too (it's the main interpreter, as /usr/bin/python or /usr/bin/ruby).
As that was a tool used by some Motus to handle packages, although
there was no package being submitted up to that date, it would have
been a pity if there was a name clash in future, so I should have
sorted out the situation.

I immediately mailed the author, sending him this mail:

- -------- Original Message --------
Message-ID:     <476AD25B.9060001 at>
Date:     Thu, 20 Dec 2007 21:36:43 +0100
From:     Giancarlo Niccolai <gc at>
User-Agent:     Thunderbird (X11/20071022)
MIME-Version:     1.0
To:     dennis at
Subject:     "Falcon" name in namespace.
X-Enigmail-Version:     0.95.0
OpenPGP:     id=12030B86;
Content-Type:     text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:     7bit


I am the author of an open source software called "The Falcon
Programming Language".  I am submitting a package to Ubuntu, and I
have been warned about possible namespace collisions.

The main concern is about the "falcon" binary file, which is the
compiler/interprter of the language (like python), and other binary
names as

Up to date, several MOTUs have checked and reported there is no
current namespace clash. I am also willing to call my package
"falconpl", which is also the name of the site:

However, it is necessary that we get in contact so that we can see if
there may be some name clash now or in the future, in order to avoid it.

I am quite open to any proposal.

I usually hang around in #ubuntu-motu or in #falconpl.

Giancarlo Niccolai.

This my reply on its reply (I think it's useless to repaste it twice)

- ------- Original Message --------
Message-ID:     <476BF4B6.8060901 at>
Date:     Fri, 21 Dec 2007 18:15:34 +0100
From:     Giancarlo Niccolai <gc at>
User-Agent:     Thunderbird (Windows/20071031)
MIME-Version:     1.0
To:     Dennis Kaarsemaker <dennis at>
Subject:     Re: "Falcon" name in namespace.
References:     <476AD25B.9060001 at>
<1198230256.6930.9.camel at mirage>
In-Reply-To:     <1198230256.6930.9.camel at mirage>
Content-Type:     text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:     7bit

Dennis Kaarsemaker wrote:
> On do, 2007-12-20 at 21:36 +0100, Giancarlo Niccolai wrote:
>> I am the author of an open source software called "The Falcon
>> Programming Language".  I am submitting a package to Ubuntu, and I
>> have been warned about possible namespace collisions.
>> The main concern is about the "falcon" binary file, which is the
>> compiler/interprter of the language (like python), and other binary
>> names as
> The places where I see collisions are
> 1) The package name
> 2) /usr/{bin,share,share/doc}/falcon
> 3) Manpage name
>> Up to date, several MOTUs have checked and reported there is no
>> current namespace clash. I am also willing to call my package
>> "falconpl", which is also the name of the site:
> Correct, 'my' falcon has not been uploaded to Ubuntu yet for a variety
> of reasons, so no conflict should exist.
>> However, it is necessary that we get in contact so that we can see if
>> there may be some name clash now or in the future, in order to avoid it.
>> I am quite open to any proposal.
> Renaming the package would unfortunately only remove two naming
> conflicts (package name and /usr/share/doc). The other conflict can only
> be resolved by renaming one of the /usr/bin/falcon files.
> I don't think it's really necessary to do that actually since both
> falcons serve two distinct niches which will have little overlap, if
> any. So my suggestion is to only rename the package and not the binary
> unless you don't mind renaming your /usr/bin/falcon to /usr/bin/falconpl
> What do you think?
Renaming the package doesn't cause any trouble. Renaming /usr/bin/falcon
would cause a bit of harassment as the automated build environment
creates a lot of dependencies (i.e. windows build system requires
falcon.exe to be there, double click shortcuts, ini files), not to talk
about #!/usr/bin/falcon headers on scripts.

About the overlap, if the language gets moment it may be virtually on
any machine, so it's a thing that we should try to work on.


P.s. I should be around somewhere this night as "jonnymind" on IRC.


I had no other communication. Just, I noticed Imbradon's notice on
revu's entry
There is already another project in the archives named "falcon" this
source and
binarys will likely have to be renamed ( and make sure both are
co-installable )

Checking the "falcon" project,

I see that the package has been loaded on "2008-01-11"; it has been
and fixed in the same day, and then immediately published.

I have been in #MOTU about every day, and I offered full and open
both to the MOTU and to this project author; My project was discussed
and seen
by the persons involved in release, yet, they just created a clean
package and
immediately published it without even bothering notifying this fact.

The chat session of this night is even more enlightening:

gen 13 20:01:04 jonnymind    imbradon:I read your notice about "there
is already a package named falcon.
gen 13 20:01:38 jonnymind    However, the notice is imprecise.
gen 13 20:02:24 *    amarillion
(n=martijn at è entrato in #ubuntu-motu
gen 13 20:02:30 jonnymind    the bug "needs packaging" for my project
has been opened in 2007, while the other package with the same name
was opened in 2008.
gen 13 20:03:18 *    cassidy` si è disconnesso (Remote closed the
gen 13 20:03:24 jonnymind    Moreover, I was negotiating with those
person about the package and binary names. We were talking about what
to do, then the conversation stopped and the other package has been
gen 13 20:03:33 jonnymind    I think we should discuss a bit the
namespace question.
gen 13 20:03:57 *    cassidy (n=cassidy at è
entrato in #ubuntu-motu
gen 13 20:06:02 jonnymind    And also, frankly decide what to do
basing on an objective criterion.
gen 13 20:08:16 jonnymind    imbradon:?


en 13 23:18:06 ScottK    jonnymind: Conflicts is more usually used for
packages that provide equivalent functionality.
gen 13 23:18:37 jonnymind    ScottK: that is absolutely true.
gen 13 23:19:13 ScottK    jonnymind: Have you discussed this with
gen 13 23:19:26 *    jekil (n=alessand at è entrato in
gen 13 23:19:38 pochu    jonnymind: (I'm not blaming you, just in case
I'm not expressing well)
gen 13 23:20:46 Nafallo    Seveas and imbrandon.
gen 13 23:20:52 *    Knightlust si è disconnesso (Read error: 104
(Connection reset by peer))
gen 13 23:20:59 TheMuso    s/c
gen 13 23:21:03 TheMuso    ugh damn keyboard
gen 13 23:21:32 jonnymind    ScottK: No, I have discussed with the
original author of the other falcon.
gen 13 23:21:45 pochu    That's Seveas.
gen 13 23:21:46 jonnymind    Well, I have started the discussion and
replied to its e-mail.
gen 13 23:21:55 jonnymind    In which he stated he wasn't going to
make a package.
gen 13 23:22:07 ScottK    jonnymind: Right, and he didn't
gen 13 23:22:15 pochu    (which is true, the package was done by
gen 13 23:22:24 pochu    ScottK: you beat me
gen 13 23:22:33 jonnymind    Ah.
gen 13 23:22:42 *    pochu is eating pizza, so he's not that fast ;)
gen 13 23:22:50 ScottK    jonnymind: My concern right now (not having
a great interest in either package) is that if you upload your package
as falcon to Debian, then it's going to cause trouble between Ubuntu
and Debian that it would be better to avoid.
gen 13 23:22:52 jonnymind    So Imbradon knew there was a falcon
package made in december.
gen 13 23:23:15 Seveas    packages for 'the other falcon' have existed
since 2006
gen 13 23:25:52 jonnymind    Seveas: again; the package here is named
falconpl now.
gen 13 23:25:59 jonnymind    That closes the question.
gen 13 23:26:30 Nafallo    both packages use /usb/bin/falcom? :-)
gen 13 23:26:36 Nafallo    s/m/n
gen 13 23:26:42 jonnymind    I do.


gen 13 23:59:19 pochu    And out of curiosity: a package needs two
ACKs to be uploaded to Universe... who did ACK falcon other than
gen 13 23:59:22 jonnymind    Nafallo: I am not changing 6 system
installation scripts and 300 doc pages for this.
gen 13 23:59:30 Nafallo    pochu: *sigh* you probably know exactly
what I mean, so why even argue about it? :-)
gen 13 23:59:36 jonnymind    Someone will find a way to package falcon
when it is included in the other distros.
gen 13 23:59:57 Seveas    pochu, could be persia, I did the final
checks with them
gen 14 00:00:26 jonnymind    I started packaging from ubuntu because I
beleived in ubuntu philosophy of respect.
gen 14 00:00:28 jonnymind    ...
gen 14 00:00:37 pochu    Seveas: I'd be surprised if it was persia
since persia was reviewing jonnymind's falcon package.
gen 14 00:01:42 pochu    And since there's no REVU upload for it to
look at, nor ACK in the needs-packaging bug...
gen 14 00:01:51 *    keffie_jayx si è disconnesso (Connection timed out)
gen 14 00:04:25 Nafallo    pochu: I just check my logs. persia :-)
gen 14 00:04:41 *    Kmos (n=gothicx at unaffiliated/kmos) è entrato in
gen 14 00:04:47 pochu    Crap.
gen 14 00:04:59 *    pochu kicks persia :)



I have a "falconpl" ubuntu package with the "Conflict: falcon" entry
in debian/control sitting on my hard disk;
it was a mediated solution suggested and required by some enlighted
MOTUs, and I gladly accepted;
but in the moment I was going to upload it I received this notification:

- ------ Original Message --------
Return-path:     <bounces at>
Envelope-to:     gc at
Delivery-date:     Sun, 13 Jan 2008 14:55:44 -0800
From:     Nafallo Bjälevik <nafallo at>
<rip headers>
X-Generated-By:     Launchpad (

This package source and binary needs to be renamed. We already have
falcon. Please make sure they are co-installable.


This was right in the middle of our discussion about name clashes and
Conflict: field.

The point is: I have opened a falcon package in Debian, and I will do
it with other distros as well, as Fedora,
Suse and Mandrake. The falcon programming language is already
installed in production environments under Windows and
MacOS; I would have gladly mediated some solution for Ubuntu
"/usr/bin/falcon" naming problem, but this
possibility has been willfully snatched away for unknown reasons. As
the space for a mediation has been
removed by this behavior which is intentionally breaking the Code of
Conduct, I am forced to resume the
technical reasons why I ask to be granted the /usr/bin/falcon program

1) Falcon P.L. is a stand-alone binary application; is a
python script proxied by an alias command.
2) The "falcon" (langauge) command is common to several architectures,
including Windows and MacOS, some
of which have special handling of application registration which is
part of our project.
3) Falcon codebase is several hundred thousands lines and growing.
Many of this lines refer to the name of
   the main interpreter. script is a relatively small
4) Falcon language (to be found as "falcon" command) is currently used
in production environments, and changing
   its name may affect third party applications.
5) Falcon language documentation is several hundreds pages long, and
reviewing it in search of the main interpreter
   name would be an extensive activity.
6) Falcon language copyright goes since 2004, with activity actually
started in 2003. has been started in
7) Falcon is known as script language name in Wikipedia
8) Falcon language Packages for other distros (i.e.) RPM will be
organized having /usr/bin/falcon.
9) Although user count between the two projects is currently not
directly comparable, the number of potential
   users of a repository utility for a specific subset of debian
distributions and a multiplatform scripting
   language is not a match.
10) Users already using Falcon would be impacted by the main
interpreter name change, as it is the base to
    launch scripts and other applications, script is only
conventionally summoned with /usr/bin/falcon
    at the command line by end-users.

It seems there isn't a single technical/objective reason why the script project should be granted
/usr/bin/falcon name, except for a direct involvement of some of the
MOTUs in its release.

I openly admit that I have opened a package request on Debiabn with
the name "falcon" as I knew about this
package being just snapped in without an open discussion. I am still
ready to negotiate the package name,
as *I* do beleive in the principles written on the Code of Conduct,
that I have signed, and I don't want
to cause unnecessary problems in a project that I still regard as a
bright example of what mankind should
be one day.

Yet, the "falcon" command will be present in many distributions, and
it is now available in many environments
and O/S. I hope the community discuss openly and peacefully this
argument considering the technical
aspects of the question.

Best regards,
Giancarlo Niccolai.


Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the ubuntu-devel mailing list