Roland Mas writes:
> I don't do much library packaging myself, but it was my understanding
> that versions of libraries that break API/ABI are meant to go in
> different binary packages, usually with a version number in the package
> name. Javascript doesn't have an ABI, but libraries written
On Sun, Oct 23, 2011 at 5:29 PM, Paul Wise wrote:
> On Sun, Oct 23, 2011 at 11:13 PM, Raphael Hertzog wrote:
>
> > And with javascript libraries, there's no failure at build time,
> > you only discover much later when something is not working...
>
> This is the crux of the issue and it is not spe
On Sun, 23 Oct 2011, Paul Wise wrote:
> > And with javascript libraries, there's no failure at build time,
> > you only discover much later when something is not working...
> This is the crux of the issue and it is not specific to JavaScript
> libraries, anything that is interpreted has this issue
Hi there.
This email isn't a criticism of rxtx - thanks Scott for accepting my patch.
It's more of a starting point for issues with development on Debian and
other
distributions - see the last comment.
On 23/10/11 15:08, Scott Howard wrote:
clone 646069 -1
retitle -1 rxtx: make -dbg package
On Sun, Oct 23, 2011 at 11:13 PM, Raphael Hertzog wrote:
> And with javascript libraries, there's no failure at build time,
> you only discover much later when something is not working...
This is the crux of the issue and it is not specific to JavaScript
libraries, anything that is interpreted ha
Raphael Hertzog, 2011-10-23 17:13:17 +0200 :
[...]
> Unfortunately, blindly replacing the file with a symlink can
> create problems of its own. Upstream tested their application
> with the version of the library that they ship. Using another
> version might break things horribly, an example here:
Hello,
I would like to discuss our handling of embedded javascript libraries.
In theory, like any other embedded library, they are to be avoided and
we have a lintian warning catching many of the common cases:
http://lintian.debian.org/tags/embedded-javascript-library.html
Unfortunately, blindly
On Sun, Oct 23, 2011 at 09:40:47AM +0200, Josselin Mouette wrote:
> Le samedi 22 octobre 2011 à 16:24 -0700, Steve Langasek a écrit :
> > > One point to think of is how this works with multiarch, which is
> > > being introduced
> > > in Debian. Instead of 'ifort' should we use the architecture tri
On Sun, 23 Oct 2011 at 10:22:42 +0100, Alastair McKinstry wrote:
> i386-linux-intel does not yet officially exist. Where are the
> triplets specified?
GNU configuration types are specified by GNU config.sub and config.guess
(distributed with autoconf, but they have their own upstream git repositor
On 2011-10-23 08:45, Enrico Zini wrote:
On Sat, Oct 22, 2011 at 04:24:23PM -0700, Steve Langasek wrote:
One point to think of is how this works with multiarch, which is
being introduced in Debian. Instead of 'ifort' should we use the
architecture triplet, eg. i386-linux-intel instead ?
Then the
On Sun, Oct 23, 2011 at 09:45:06AM +0200, Enrico Zini wrote:
> Alastair to answer that bit. My understanding on library use and ABI
> compatibilities is that the critical point are .mod files in
> /usr/include, whereas .a or .so files are perfectly reusable across
> compilers.
I stand corrected:
On Sat, Oct 22, 2011 at 04:24:23PM -0700, Steve Langasek wrote:
> > One point to think of is how this works with multiarch, which is
> > being introduced in Debian. Instead of 'ifort' should we use the
> > architecture triplet, eg. i386-linux-intel instead ?
> > Then the libraries go in i386-linux
Le samedi 22 octobre 2011 à 16:24 -0700, Steve Langasek a écrit :
> > One point to think of is how this works with multiarch, which is
> > being introduced
> > in Debian. Instead of 'ifort' should we use the architecture triplet, eg.
> > i386-linux-intel instead ?
> > Then the libraries go in i386
13 matches
Mail list logo
