On Thu, Jan 3, 2013 at 12:17 PM, Alastair McKinstry
wrote:
> On 2013-01-03 08:41, Reinhard Tartler wrote:
>> On Wed, Jan 2, 2013 at 10:26 PM, Wouter Verhelst wrote:
>>> On Wed, Jan 02, 2013 at 01:05:46PM +0100, Guillem Jover wrote:
- Private dependencies, as they leak to rdeps. When a li
On Thu, Jan 03, 2013 at 09:41:15AM +0100, Reinhard Tartler wrote:
> On Wed, Jan 2, 2013 at 10:26 PM, Wouter Verhelst wrote:
> > On Wed, Jan 02, 2013 at 01:05:46PM +0100, Guillem Jover wrote:
> >> - Private dependencies, as they leak to rdeps. When a library uses
> >> another library priv
Paul Wise writes:
> With Built-Using, we get a way to rebuild packages that embed parts of
> other packages:
>
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using
>
> Not sure if the buildd stuff will automatically schedule rebuilds or
> if we will notice due to britney k
On Thu, Jan 3, 2013 at 8:04 PM, Florian Weimer wrote:
> One might argue that the static case is actually better because it is
> more predictable, but our post-release support model is heavily
> dependent on minimal changes (because we cannot do full QA
> post-release). Such minimal changes are im
* Michael Stapelberg:
> Hi Florian,
>
> Florian Weimer writes:
>>> Could you provide an example please? I don’t understand how this is
>>> different with static linking than with dynamic linking yet.
>>
>> With dynamic linking, you pick up the behavior change along with
>> "apt-get upgrade", so I
Hi Florian,
Florian Weimer writes:
>> Could you provide an example please? I don’t understand how this is
>> different with static linking than with dynamic linking yet.
>
> With dynamic linking, you pick up the behavior change along with
> "apt-get upgrade", so I expect that we get much more tes
* Sune Vuorela:
> On 2013-01-03, Alastair McKinstry wrote:
>> (1) pkg-config files for libraries, in particular all those that ship
>> static libs, to be a
>> release goal for jessie.
>
> rather get rid of static libs.
We might want to extend static libraries with LTO data one day.
(We could eve
On 2013-01-03, Alastair McKinstry wrote:
> (1) pkg-config files for libraries, in particular all those that ship
> static libs, to be a
> release goal for jessie.
rather get rid of static libs.
> It would be useful / interesting if pkg-config information could be used
> to generate dependencies
* Michael Stapelberg:
> Florian Weimer writes:
>> My main worry is that, for example, a fix in another, otherwise
>> unrelated dependency prompts a rebuild, and this picks up behavioral
>> changes which haven't been visible before, but lingering in the static
>> library. Essentially, we end up w
Hi Florian,
Florian Weimer writes:
> My main worry is that, for example, a fix in another, otherwise
> unrelated dependency prompts a rebuild, and this picks up behavioral
> changes which haven't been visible before, but lingering in the static
> library. Essentially, we end up with non-reproduc
On 2013-01-03 08:41, Reinhard Tartler wrote:
> On Wed, Jan 2, 2013 at 10:26 PM, Wouter Verhelst wrote:
>> On Wed, Jan 02, 2013 at 01:05:46PM +0100, Guillem Jover wrote:
>>> - Private dependencies, as they leak to rdeps. When a library uses
>>> another library privately this dependency ge
Hi Reinhard,
Reinhard Tartler writes:
> Consider this from the application perspective: Say an application
> links against a library libfoo.a. At some point, libfoo decides to
> include compression support, and requires functionality from libz. No
> problem for the library package maintainer; he
* Wouter Verhelst:
> Strictly speaking, if you're only using static libraries this is not
> really true; once you've compiled something against a static library,
> the static library might change in whatever way it sees fit, the
> compiled binary will continue to work, with or without recompilatio
On Wed, Jan 2, 2013 at 10:26 PM, Wouter Verhelst wrote:
> On Wed, Jan 02, 2013 at 01:05:46PM +0100, Guillem Jover wrote:
>> - Private dependencies, as they leak to rdeps. When a library uses
>> another library privately this dependency gets linked in directly
>> in all other rdeps,
On Wed, Jan 02, 2013 at 01:05:46PM +0100, Guillem Jover wrote:
> - 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 depe
Hi Shawn,
shawnland...@gmail.com writes:
> [...]
> use of these .a files. You have to look at the resulting binaries.
But in this discussion we are talking about building _library_ packages,
not binaries. I would like to focus on the question of how to build a Go
package (such as github.com/mstap/
Michael Stapelberg wrote:
>Hi Shawn,
>
>shawnland...@gmail.com writes:
>> I am not sure how or if lld works on .a files, but I am pretty sure
>> that this binary is linked against libc6 and libgo1. If I invoke
>gccgo
>> directly that is the result.
>If by “this binary” you mean godebiancontrol.
Hi Shawn,
shawnland...@gmail.com writes:
> I am not sure how or if lld works on .a files, but I am pretty sure
> that this binary is linked against libc6 and libgo1. If I invoke gccgo
> directly that is the result.
If by “this binary” you mean godebiancontrol.a, then no:
ldd /tmp/golang/pkg/linux
Michael Stapelberg wrote:
>Hi Matthias,
>
>Matthias Klose writes:
>> Calling gc the "official" compiler seems to be misleading. gccgo in
>That’s why I called it “official”, not official.
>
>> wheezy supports the Go API 1.0, and the standard library 1.0.3,
>> supports dynamic linking, supports
Hi Matthias,
Matthias Klose writes:
> Calling gc the "official" compiler seems to be misleading. gccgo in
That’s why I called it “official”, not official.
> wheezy supports the Go API 1.0, and the standard library 1.0.3,
> supports dynamic linking, supports multiarch, makes the distinction
> for
* Matthias Klose , 2013-01-02, 15:17:
I don't mind having a second compiler in the archives
How generous of you!
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists
Am 02.01.2013 03:54, schrieb 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.
>
>> AFAIK not, but I
On 2013-01-02, Michael Stapelberg wrote:
>> * 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).
> How is this any different from a ???normal??
Hi Guillem,
Thanks for your explanations, most points make sense to me. Two
questions remain:
Guillem Jover writes:
> - 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
On 1 January 2013 19:47, Michael Stapelberg wrote:
> Hi Dmitrijs,
>
> Dmitrijs Ledkovs 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
* 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 chan
On Wed, 2013-01-02 at 09:15:59 +0100, Michael Stapelberg wrote:
> Shawn 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 p
Hi Bernhard,
"Bernhard R. Link" 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
* Michael Stapelberg [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 t
❦ 2 janvier 2013 09:15 CET, Michael Stapelberg :
>> 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 pro
Hi Shawn,
Shawn 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
linki
Hi Bernhard,
"Bernhard R. Link" 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
cons
On Wed, Jan 2, 2013 at 3:15 PM, Bernhard R. Link 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?
http://wiki.d
* Michael Stapelberg [130101 14:45]:
> Furthermore, the package names should be e.g. “golang-codesearch” for
> the library code.google.com/p/codesearch
Please also consider "codesearch-golang". Especially with longer package
names not everything can show the full name so the beginning should be
t
On Tue, Jan 1, 2013 at 6:54 PM, Paul Wise wrote:
> 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.
>
go also
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.
> AFAIK not, but I will add this to the list of questions I want to ask
Hi Simon,
Simon McVittie writes:
> Where does gccgo look for Go sources (src)?
> Where does gccgo look for Go "static libraries" (pkg)?
> Where does gccgo look for Go dynamic libraries? (Presumably the same
> places where gcc looks for C dynamic libraries?)
I can’t really answer these questions i
On 01/01/13 16:14, Michael Stapelberg wrote:
> Hi Paul,
>> Support dynamic linking? That would avoid the whole rebuild-the-world
>> thing that statically-linked languages have.
> Only when not using the “official” compiler (gc), e.g. gccgo has support
> for dynamic linking.
Where does gccgo look f
Hi Dmitrijs,
Dmitrijs Ledkovs writes:
> What about multiarch?
I tried to address this on the wiki page, see
http://wiki.debian.org/MichaelStapelberg/GoPackaging#Multi-Arch.2Fcross-compiling
Essentially, I currently believe that multi-arch does not make sense for
go, since we are only dealing wit
On 1 January 2013 15:44, Michael Stapelberg
wrote:
> Hi,
>
> I am co-maintainer of the golang package and spent a few hours on trying
> to figure out how to best create Debian packages for libraries and
> programs which are implemented in Go.
>
> I have documented my thoughts, conclusions and exam
Hi Paul,
> Since golang apparently doesn't support dynamic linking, every package
> built against a golang library will have to include an appropriate
> Built-Using header. You will probably also want a lintian test for
> this to autoreject anything without this header.
Thanks, I was not aware of
On Tue, Jan 1, 2013 at 9:44 PM, Michael Stapelberg wrote:
> Any feedback is appreciated. Please read the wiki page before you
> comment, it contains more rationale than this email. Thanks.
Since golang apparently doesn't support dynamic linking, every package
built against a golang library will h
Hi,
I am co-maintainer of the golang package and spent a few hours on trying
to figure out how to best create Debian packages for libraries and
programs which are implemented in Go.
I have documented my thoughts, conclusions and example packaging on:
http://wiki.debian.org/MichaelStapelberg/GoPac
43 matches
Mail list logo
