[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2



Don Armstrong escreveu isso aí:
> On Mon, 23 Jan 2012, Jakub Wilk wrote:
> > I normally advocate using upstream name for source package name
> > (even if it's a single binary package and the binary package would
> > have a different name due to $LANGUAGE policy).
> 
> If you are only building one binary package, the source package should
> have the same name. The exception to this guideline is when the binary
> package name is expected to change over the lifetime of the source
> package. [For example, if the binary name contains a soname.]
> 
> Otherwise you can end up with confusing cases where a package with
> source foo builds binary bar, and binary foo is built by source bar.
> 
> The language guidelines for binary packages exist to avoid cluttering
> the package namespace, and they should generally be applied to source
> packages too.

Another argument in favor of using the same name for source and binary
packages: suppose there is "libfoo", and independent bindings for Perl,
Python and Ruby, all called "foo", and that "foo" is unique in their
respective upstream language-specific namespaces (CPAN/PyPi/Rubygems);
which one gets to use the 'foo' source package name in Debian? First
come first serve won't work.

BTW DEP-5 proposes a explicit field in debian/copyrigh for the upstream
name of packages, so machine discovery of this information should not
be too hard.

-- 
Antonio Terceiro <terceiro@debian.org>

Attachment: signature.asc
Description: Digital signature


Reply to: