FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-23-2012, 08:30 PM
Russ Allbery
 
Default Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

Sandro Tosi <morph@debian.org> writes:
> On Mon, Jan 23, 2012 at 22:06, Russ Allbery <rra@debian.org> wrote:

>> python-futures for the package name, surely, no?

> do you mean the binary? that will be python-concurrent.futures, as per
> python policy; for the source I'm open to comments

I was thinking of the source. If you're building a single binary package
from the source package, it's usually better for everyone's level of
confusion to just name the source package the same as the binary package.
But my main point was just to avoid having a source package named
"futures"; that's a little general.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r4yqf6nu.fsf@windlord.stanford.edu">http://lists.debian.org/87r4yqf6nu.fsf@windlord.stanford.edu
 
Old 01-23-2012, 08:44 PM
Jakub Wilk
 
Default Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

* Russ Allbery <rra@debian.org>, 2012-01-23, 13:30:

python-futures for the package name, surely, no?
do you mean the binary? that will be python-concurrent.futures, as per
python policy; for the source I'm open to comments
I was thinking of the source. If you're building a single binary
package from the source package, it's usually better for everyone's
level of confusion to just name the source package the same as the
binary package. But my main point was just to avoid having a source
package named "futures"; that's a little general.


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). However, in this case I agree
that "futures" would be too generic.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120123214454.GA7581@jwilk.net">http://lists.debian.org/20120123214454.GA7581@jwilk.net
 
Old 01-23-2012, 09:13 PM
Russ Allbery
 
Default Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

Jakub Wilk <jwilk@debian.org> writes:

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

This can make things unnecessarily awkward and confusing for, say, the
BTS. Nothing that people can't deal with, but in the Perl group we had a
discussion about this a while back and decided to always stick with
calling the source package and the binary package the same thing if the
source only builds one binary.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ehuqf4nx.fsf@windlord.stanford.edu">http://lists.debian.org/87ehuqf4nx.fsf@windlord.stanford.edu
 
Old 01-23-2012, 09:16 PM
Don Armstrong
 
Default Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

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.


Don Armstrong

--
2: There is no out. There is only in.
-- "The Prisoner (2009 Miniseries)"

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120123221619.GD21080@rzlab.ucr.edu">http://lists.debian.org/20120123221619.GD21080@rzlab.ucr.edu
 
Old 01-25-2012, 11:12 AM
Antonio Terceiro
 
Default 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>
 
Old 01-25-2012, 12:18 PM
Jakub Wilk
 
Default Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

* Antonio Terceiro <terceiro@debian.org>, 2012-01-25, 10:12:
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?


None of them, of course.

This is an argument for naming source packages in a sane way when your
upstream for some reasons could do that himself... Not much to do with
$binarypackagename==$sourcepackagename, really.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120125131842.GA8949@jwilk.net">http://lists.debian.org/20120125131842.GA8949@jwilk.net
 
Old 01-26-2012, 11:09 PM
Antonio Terceiro
 
Default Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

Jakub Wilk escreveu isso aí:
> * Antonio Terceiro <terceiro@debian.org>, 2012-01-25, 10:12:
> >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?
>
> None of them, of course.
>
> This is an argument for naming source packages in a sane way when
> your upstream for some reasons could do that himself... Not much to
> do with $binarypackagename==$sourcepackagename, really.

What's sane for us is not what's sane for upstream. Having a unique
name in PyPi is perfectly sane for Python developers, and they won't
check every other language archive to make sure their package name
doesn't clash with any other package in any other language.

Debian, on the other hand, requires a globally unique name. Acting
consistently and sticking to the per-language standards for naming
packages, including source packages, is the Debian solution for
guaranteeing a unique name.

--
Antonio Terceiro <terceiro@debian.org>
 

Thread Tools




All times are GMT. The time now is 10:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org