date:20130102

Re: [RFC] Go (golang) packaging

2013-01-02 Thread Michael Stapelberg

Hi Bernhard,

Bernhard R. Link brl...@debian.org writes:
 Please also consider codesearch-golang. Especially with longer package
 names not everything can show the full name so the beginning should be
 the more important information.
Given that we already have python-* and ruby-*, I’d find golang-* more
consistent. Which specific tools/places do you have in mind that have to
truncate package names?

 (and of course just “codesearch” for the binaries).

 I assume s/binaries/sources/? And I'd suggest to just not policy the
No, I really meant binaries, as in “cgrep”, “cindex” and “csearch” in
this specific case.

 Another question: Have you considered asking for a archive Section for
 those packages? I guess with no special section yet all those packages
 would be section libdevel as they are for static linking only, wouldn't
 they?
As pabs has pointed out, I did that, but the general rule of thumb is
that we want to have lots of packages first and an archive section
second.

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x67gnwngtf@midna.zekjur.net

Re: [RFC] Go (golang) packaging

2013-01-02 Thread Michael Stapelberg

Hi Shawn,

Shawn shawnland...@gmail.com writes:
 Henceforth when a go program depends on a go library, those go
 libraries are ALWAYS compiled in statically. Static linking causes
 many problems for distributions like Debian, and therefore this
Can you please tell us which specific problems are caused by static
linking for Debian? I’m not aware of any.

I’m somewhat hesitant to say “Let’s just use gccgo in Debian” because
static linking is one of the advantages of Go (IMO, but also a shared
feeling by the community I think) and the gc compiler is fast, which is
another advertised advantage.

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x64nj0ngow@midna.zekjur.net

Re: [RFC] Go (golang) packaging

2013-01-02 Thread Vincent Bernat

 ❦  2 janvier 2013 09:15 CET, Michael Stapelberg stapelb...@debian.org :

 Henceforth when a go program depends on a go library, those go
 libraries are ALWAYS compiled in statically. Static linking causes
 many problems for distributions like Debian, and therefore this
 Can you please tell us which specific problems are caused by static
 linking for Debian? I’m not aware of any.

Fixin a bug (including a security bug) in a package means recompiling
all packages depending on this package.
-- 
panic(CPU too expensive - making holiday in the ANDES!);
2.2.16 /usr/src/linux/arch/mips/kernel/traps.c


pgp53DWVMB_Ew.pgp
Description: PGP signature

Re: [RFC] Go (golang) packaging

2013-01-02 Thread Bernhard R. Link

* Michael Stapelberg stapelb...@debian.org [130102 09:13]:
 Given that we already have python-* and ruby-*, I’d find golang-* more
 consistent.

We also have lib*-perl.
Ruby seems to have changed recently from lib*-ruby to ruby-*. (Does
anyone know of the reason that changed? For I only remember all the
reasons for the old naming scheme and see no reasons in favor of the new)

 Which specific tools/places do you have in mind that have to
 truncate package names?

Most GUIs will truncate depending on the size of the window.

  (and of course just “codesearch” for the binaries).
 
  I assume s/binaries/sources/? And I'd suggest to just not policy the
 No, I really meant binaries, as in “cgrep”, “cindex” and “csearch” in
 this specific case.

And what is the name of the binary package those programs will be in?

  Another question: Have you considered asking for a archive Section for
  those packages? I guess with no special section yet all those packages
  would be section libdevel as they are for static linking only, wouldn't
  they?
 As pabs has pointed out, I did that, but the general rule of thumb is
 that we want to have lots of packages first and an archive section
 second.
Too avoid packaging mistakes and to have the wording ready I'd suggest
to already prepare the wording (I guess in the section later will be
everything that is is now in libdevel plus golong toolchain packages,
while everything providing programs to be in their respective section).

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130102090022.ga5...@client.brlink.eu

Re: [RFC] Go (golang) packaging

2013-01-02 Thread Michael Stapelberg

Hi Bernhard,

Bernhard R. Link brl...@debian.org writes:
  (and of course just “codesearch” for the binaries).
 
  I assume s/binaries/sources/? And I'd suggest to just not policy the
 No, I really meant binaries, as in “cgrep”, “cindex” and “csearch” in
 this specific case.

 And what is the name of the binary package those programs will be in?
“codesearch”, as I wrote.

  Another question: Have you considered asking for a archive Section for
  those packages? I guess with no special section yet all those packages
  would be section libdevel as they are for static linking only, wouldn't
  they?
 As pabs has pointed out, I did that, but the general rule of thumb is
 that we want to have lots of packages first and an archive section
 second.
 Too avoid packaging mistakes and to have the wording ready I'd suggest
 to already prepare the wording (I guess in the section later will be
 everything that is is now in libdevel plus golong toolchain packages,
 while everything providing programs to be in their respective section).
Which wording do you mean?

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x61ue4ne3d@midna.zekjur.net

Re: lib*-java, D packaging

2013-01-02 Thread Thomas Koch

Bernhard R. Link:
 * Michael Stapelberg stapelb...@debian.org [130102 09:13]:
  Given that we already have python-* and ruby-*, I’d find golang-* more
  consistent.
 
 We also have lib*-perl.
and lib*-java, but the java packaging might not be the best place to look for 
best practices? (Since we're few people.)

I'm also following this thread to look for ideas for the D language which has 
similar packaging characteristics like go as it seems.

Regards,

Thomas Koch, http://www.koch.ro


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201301021156.09095.tho...@koch.ro

Re: [RFC] Go (golang) packaging

2013-01-02 Thread Guillem Jover

On Wed, 2013-01-02 at 09:15:59 +0100, Michael Stapelberg wrote:
 Shawn shawnland...@gmail.com writes:
  Henceforth when a go program depends on a go library, those go
  libraries are ALWAYS compiled in statically. Static linking causes
  many problems for distributions like Debian, and therefore this

 Can you please tell us which specific problems are caused by static
 linking for Debian? I’m not aware of any.

Well, that's surprising, I would have thought this has been discussed
at lenght in the past, in any case here are several reasons (I'm most
probably forgetting others):

  * Changes in libraries might require recompiling all of their rdeps.
This includes:
- Bug fixes (security or otherwise, as pointed out in the thread).
- Performance improvements.
- Private dependencies, as they leak to rdeps. When a library uses
  another library privately this dependency gets linked in directly
  in all other rdeps, when that library stop depending on that
  private dependency, all rdeps need to be rebuilt.
  * We might need to keep the sources for all library instances that
have been linked into any other package, to comply with license
conditions (see the Built-Using comment on this thread too).
  * Larger dependency chains. Because private libraries need to be
pulled in even by indirect dependencies, the sources and static
libraries need to be available at compile time, this means the
libfoo-dev dependencies and Build-Depends chains are going to
be larger.
  * Produces huge binaries (and packages), which use more memory that
cannot be shared across processes (unlike shared libraries).

The first point alone, make such things a PITA to manage in a
distribution, and are a waste of buildd and people's time who need
to coordinate those things. The rest imply a waste of resources or
added complexity which could be avoided.

 I’m somewhat hesitant to say “Let’s just use gccgo in Debian” because
 static linking is one of the advantages of Go (IMO, but also a shared
 feeling by the community I think) and the gc compiler is fast, which is
 another advertised advantage.

While it's true that static linking can produce varying degrees of faster
binaries depending on the conditions (architecture, amount of libraries,
etc), I don't think it's worth the tradeoff for the general case and I'm
having a hard time seeing a new compiled system language that does not
support shared libraries as a serious contender.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130102120546.ga31...@gaara.hadrons.org

Re: [RFC] Go (golang) packaging

2013-01-02 Thread Florian Weimer

* Paul Wise:

 On Wed, Jan 2, 2013 at 12:14 AM, Michael Stapelberg wrote:

 Only when not using the “official” compiler (gc), e.g. gccgo has support
 for dynamic linking.

 Then we should use gccgo until the official compiler supports this.

gccgo supports dynamic linking, but Go 1 API changes may break the
ABI.  Struct sizes and and field offsets are compiled into reverse
dependencies, but the Go 1 API promise does not prevent changes in
this area.

There are ways to solve this (sizes and offsets have to be provided by
the dynamic linker), but there is a performance impact.  I think this
has been done for GCJ.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8738yjsrru@mid.deneb.enyo.de

Re: [RFC] Go (golang) packaging

2013-01-02 Thread Dmitrijs Ledkovs

On 1 January 2013 19:47, Michael Stapelberg stapelb...@debian.org wrote:
Hi Dmitrijs,

Dmitrijs Ledkovs x...@debian.org writes:
What about multiarch?
I tried to address this on the wiki page, see
http://wiki.debian.org/MichaelStapelberg/GoPackaging#Multi-Arch.2Fcross-compiling

I was more concerned about future-proof, e.g. in debian we have
distinct armel armhf and currently with multiarch I can
cross-compile binaries for either target from my amd64 build-machine.
In debian we have far more ports than any other distros. It would be
nice if go could use gnu and/or debian triplets instead of one more
incomplete set for the same thing.

Essentially, I currently believe that multi-arch does not make sense for
go, since we are only dealing with static binaries. E.g. to run an i386
program, you don’t need any additional libraries:

I understand that users running the resulting binaries typically do
not need anything.
My interest in multi-arch support is for fast cross-compilation, i.e.
the same reason pre-compiled libraries are shipped for native
compilation.
I could use chroots, but having all those packages as M-A: same
would be lovely... which brings the argument back into the circle that
upstream doesn't define unique per-arch paths (at least not for arm*)

reference: https://wiki.ubuntu.com/MultiarchCross

Regards,

Dmitrijs.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/canbhlujnv-_h6+buolbwr-ae4+oispqw+q8epojupadwzbj...@mail.gmail.com

70 matches

Mail list logo