Hi,
Am Mittwoch, den 06.02.2013, 16:31 -0800 schrieb Russ Allbery:
Normal
versioning problems that we just take for granted in C, such as allowing
the coexistence of two versions of the same library with different ABIs on
the system at the same time without doing the equivalent of static
* Hilko Bengen:
I drew a different conclusion from Ian's messages the thread you
mentioned (see the quotes below). Apparently, one *can* build shared
libraries using gccgo, but they are not currently usable using dlopen().
My impression was that this means that regular use of shared libraries
On Wed, Feb 06, 2013 at 04:31:55PM -0800, Russ Allbery wrote:
I keep being tempted to go off on a rant about how we have all of these
modern, sophisticated, much more expressive programming languages, and yet
still none of them handle ABI versioning as well as C does. Normal
versioning
On Thu, Feb 07, 2013 at 08:54:32AM +0800, Paul Wise wrote:
Why did Debian have to invent /usr/share/pyshared and symlink farms in
/usr/lib/pythonX.Y instead of upstream having something like that in
the default install and search paths?
This is all resolved now in python3. There is no more
* Steve Langasek:
Actually, if you look closely, you'll find that the traditional Java
.jar linking resolver precisely mirrors the behavior of the C linker
on Solaris from the same era (allows you to link dynamically, but
requires top-level objects to be linked at build time with all the
Russ Allbery r...@debian.org writes:
I keep being tempted to go off on a rant about how we have all of
these modern, sophisticated, much more expressive programming
languages, and yet still none of them handle ABI versioning as well as
C does. Normal versioning problems that we just take for
On Thu, 7 Feb 2013 20:16:18 +
Matthew Woodcraft matt...@woodcraft.me.uk wrote:
I don't think it's as clear-cut as that.
Debian handles multiple versions of C libraries at _runtime_ well, but I
think its support for C libraries still leaves a good deal to be
desired: it doesn't let you
Neil Williams codeh...@debian.org writes:
Matthew Woodcraft matt...@woodcraft.me.uk wrote:
I don't think it's as clear-cut as that.
Debian handles multiple versions of C libraries at _runtime_ well, but
I think its support for C libraries still leaves a good deal to be
desired: it doesn't
On 07/02/2013 09:16, Steve Langasek wrote:
Debian's Python build helper tools are still breeding like rabbits,
there is a new one in experimental. I guess because the current ones
dh_python2/dh_python3 don't handle packages that contain only code
that runs on both python2 and python3
Chow Loong Jin hyper...@debian.org writes:
Well, relative to other languages, I think Python's had the most changes
with regards to build helper tools -- there was dh_pycentral, and
dh_pysupport in the past which did more or less the same thing in
different ways, and now we have dh_python2,
On Fri, Feb 08, 2013 at 10:00:47AM +0800, Chow Loong Jin wrote:
On 07/02/2013 09:16, Steve Langasek wrote:
Debian's Python build helper tools are still breeding like rabbits,
there is a new one in experimental. I guess because the current ones
dh_python2/dh_python3 don't handle packages
On 08/02/2013 10:07, Steve Langasek wrote:
On Fri, Feb 08, 2013 at 10:00:47AM +0800, Chow Loong Jin wrote:
[...]
Well, relative to other languages, I think Python's had the most changes
with regards to build helper tools -- there was dh_pycentral, and
dh_pysupport in the past which did more
On Tue, 05 Feb 2013 23:44:30 +0100
Hilko Bengen ben...@debian.org wrote:
* Adam Borowski:
The worst case scenario IMHO is some people invest a lot of time to
make the Debianized-Go stuff quite divergent from upstream, people's
expectations of how things behave in Go-land are broken when
On Wed, Feb 06, 2013 at 09:23:02AM +, Neil Williams wrote:
Then don't package Go at all and leave it entirely outside the realm of dpkg
- no dependencies allowed in either direction, no files created outside
/usr/local for any reason, no contamination of the apt or dpkg cache data. If
what
Neil Williams codeh...@debian.org writes:
If Go wants to be packaged, it complies by the requirements of
packaging. If it wants to live the life of a hermit and disappear up
itself, that's fine but then it doesn't get the privilege of interacting
with the rest of Debian. It's just a user
* Neil Williams:
If what you want is complete separation, why is there even a long
running thread on integration?
Sorry if I failed to make myself clear:
I want excellent Debian packages of the compiler/runtime/tools *and*
libraries *and* still make it possible for our users to use upstream's
Hilko Bengen, 2013-02-06 14:46:11 +0100 :
[...]
I am pretty sure that if you asked about packaging software in the
Python, Perl, Ruby, Java, Lua communities, you would get recommendations
to not use Debian packages at all and get pointers to what the
respective community considers a solution
* Roland Mas:
Hilko Bengen, 2013-02-06 14:46:11 +0100 :
[...]
I am pretty sure that if you asked about packaging software in the
Python, Perl, Ruby, Java, Lua communities, you would get recommendations
to not use Debian packages at all and get pointers to what the
respective community
On Feb 06, 2013, at 03:26 PM, Roland Mas wrote:
I can only speak about Python and Perl, but I don't remember *ever* having
been told to use their deployment system instead of the packaged versions of
the interpreter and modules. The closest I've seen is something like if
you're running CentOS or
Barry Warsaw ba...@python.org writes:
Where things get tricky is if you have multiple applications that need
different versions of its dependencies. Say Debian has python-foo 1.2
which application Bar needs, but application Baz needs python-foo 2.0.
Despite years of discussion, in Debian,
On Thu, Feb 7, 2013 at 8:19 AM, Barry Warsaw wrote:
Speaking with many hats on, I think Debian Python has done a very admirable
job of integrating the Python ecosystem with Debian.
One of the pain points for users (I've had folks ask me this
face-to-face) with that stuff was site-packages vs
Am 07.02.2013 01:54, schrieb Paul Wise:
On Thu, Feb 7, 2013 at 8:19 AM, Barry Warsaw wrote:
Speaking with many hats on, I think Debian Python has done a very admirable
job of integrating the Python ecosystem with Debian.
One of the pain points for users (I've had folks ask me this
Okay, fortunately, no bands are practicing tonight and no kids need homework
help, so let's see if I can answer some of these questions. :)
On Feb 07, 2013, at 08:54 AM, Paul Wise wrote:
On Thu, Feb 7, 2013 at 8:19 AM, Barry Warsaw wrote:
Speaking with many hats on, I think Debian Python has
On Fri, Feb 01, 2013 at 01:27:05PM -0800, Russ Allbery wrote:
Lennart Sorensen lsore...@csclub.uwaterloo.ca writes:
Not all C libraries are distributed from one central site and they
certainly don't expect you to use a central package installation system.
So much more the shame for C.
On Fri, Feb 01, 2013 at 03:20:08PM -0500, Lennart Sorensen wrote:
On Fri, Feb 01, 2013 at 10:00:32AM +, Jon Dowland wrote:
As a Haskell developer, I find cabal much more convenient than nothing,
in the situation where the library I want is not packaged by Debian yet.
If I want my
On Fri, Feb 01, 2013 at 12:38:16PM -0800, Russ Allbery wrote:
Using Debian packages is a *means*, not an *end*. Sometimes in these
discussions I think people lose sight of the fact that, at the end of the
day, the goal is not to construct an elegantly consistent system composed
of
On Fri, Feb 01, 2013 at 04:02:18PM -0500, Lennart Sorensen wrote:
For cpan there is even dh-make-perl. The solution then is to make
equivelant scripts for other languages. The solution is NOT to use some
other package installation system.
Although I've never used dh-make-perl myself, I'm
Jon Dowland j...@debian.org writes:
Although I've never used dh-make-perl myself, I'm lead to believe that
it is perhaps *the* most successful tool of its type (that is, of things
that create .debs from packages in an alternative repository system like
CPAN, gems, cabal, etc.), and that it
On Tue, Feb 05, 2013 at 05:30:51PM +, Jon Dowland wrote:
And in particular, where a problem cannot be solved in pure Debian, I don't
want Debian to interfere with the bit of the solution that lives outside of
its domain. That may include not attempting to package/patch/alter/adjust
* Adam Borowski:
The worst case scenario IMHO is some people invest a lot of time to
make the Debianized-Go stuff quite divergent from upstream, people's
expectations of how things behave in Go-land are broken when they
access Go-via-Debian
Just think what would happen if every single
Hi Hilko,
Hilko Bengen ben...@debian.org writes:
/usr/local. This is not what sudo go get currently (version 1:1.0.2-2)
does -- it happily puts both source and binary files into GOROOT
(=/usr/lib/go). This is bound to break things in interesting ways at
some point.
Indeed. This is when having
* Michael Stapelberg:
Hilko Bengen ben...@debian.org writes:
/usr/local. This is not what sudo go get currently (version 1:1.0.2-2)
does -- it happily puts both source and binary files into GOROOT
(=/usr/lib/go). This is bound to break things in interesting ways at
some point.
Indeed. This
Michael,
after re-reading your GoPackaging Wiki page and digging around a bit in
the sources for the go tool, I think that only minimal changes to go(1)
are needed for its build system to Just Work without breaking
expectations:
1. Debian user's/admin's perspective: As I have already written
On Wed, Jan 30, 2013 at 06:46:35PM -0500, Lennart Sorensen wrote:
Absolutely. As a user I have a nice package management system that I
know how to use and which works well. I don't need another one.
As a Haskell developer, I find cabal much more convenient than nothing,
in the situation where
Excerpts from Chow Loong Jin's message of 2013-01-29 19:15:01 -0800:
Having multiple package managers which don't know about each other on a system
is evil™ (but in some cases, can be managed properly).
Robert Collins did a nice write up on this very subject not long ago:
On Fri, Feb 01, 2013 at 10:00:32AM +, Jon Dowland wrote:
As a Haskell developer, I find cabal much more convenient than nothing,
in the situation where the library I want is not packaged by Debian yet.
If I want my haskell libraries and programs to reach a wide audience, I
need to learn
On Fri, Feb 01, 2013 at 10:45:33AM -0800, Clint Byrum wrote:
Excerpts from Chow Loong Jin's message of 2013-01-29 19:15:01 -0800:
Having multiple package managers which don't know about each other on a
system
is evil™ (but in some cases, can be managed properly).
Robert Collins did a
Lennart Sorensen lsore...@csclub.uwaterloo.ca writes:
On Fri, Feb 01, 2013 at 10:00:32AM +, Jon Dowland wrote:
As a Haskell developer, I find cabal much more convenient than nothing,
in the situation where the library I want is not packaged by Debian
yet. If I want my haskell libraries
On Fri, Feb 01, 2013 at 12:38:16PM -0800, Russ Allbery wrote:
I hope that's not generally true, because that would be horribly
depressing. I don't believe that's true of the Perl community in general.
It's certainly not true of the C or Java community!
Not all C libraries are distributed from
Lennart Sorensen lsore...@csclub.uwaterloo.ca writes:
On Fri, Feb 01, 2013 at 12:38:16PM -0800, Russ Allbery wrote:
I hope that's not generally true, because that would be horribly
depressing. I don't believe that's true of the Perl community in
general. It's certainly not true of the C or
* Russ Allbery r...@debian.org [130201 21:38]:
If you want bleeding edge, then you are not a normal user and you
certainly aren't a system administrator that wants to keep a controlled
system they can reproduce.
Speak for yourself. I've been a system administrator for twenty years,
and
On 31/01/2013 13:32, Jean-Christophe Dubacq wrote:
Don't forget package.el for emacs!
Wait, what? package.el uses Ruby, and not elisp?
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
On 31 January 2013 08:25, Chow Loong Jin hyper...@debian.org wrote:
On 31/01/2013 13:32, Jean-Christophe Dubacq wrote:
Don't forget package.el for emacs!
Wait, what? package.el uses Ruby, and not elisp?
How did we start a thread on go packaging and now mention TeX Live
package manager
Chow,
am Thu, Jan 31, 2013 at 09:44:27AM +0800 hast du folgendes geschrieben:
Well, really, the manageable case I was talking about was pip/easy_install
inside a Python virtualenv, which is basically a Python installation that is
kept completely distinct from the system's installation and
On Jan 31, 2013, at 09:44 AM, Chow Loong Jin wrote:
Well, really, the manageable case I was talking about was pip/easy_install
inside a Python virtualenv, which is basically a Python installation that is
kept completely distinct from the system's installation and doesn't touch
anything dpkg is
On 01/02/2013 05:23, Barry Warsaw wrote:
This arrangement works pretty well for me in practice, especially since
`virtualenv --system-site-packages` can usually give you the mix you need.
Yes it does in most cases, but --system-site-packages can do the wrong thing in
certain edge-cases like
Hi Chow,
Chow Loong Jin hyper...@debian.org writes:
1. If software that depends on native packages is installed using go get
or whatever other language-specific package manager, e.g. pip for Python
or
gem for Ruby is installed, there is no way to declare a dependency on
those.
On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
I would add one thing here: Haskell/GHC also (currently) doesn't create
shared libraries, and instead builds the program statically, but the
Debian Haskell group still tries to package as best as they can the
development libraries, for all
On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
Having multiple package managers which don't know about each other on a system
is evil™ (but in some cases, can be managed properly).
Some integration between dpkg and domain-specific package managers
could be useful. With DEP-11, we
Le 30/01/2013 09:55, Paul Wise a écrit :
On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
Having multiple package managers which don't know about each other on a
system
is evil™ (but in some cases, can be managed properly).
Some integration between dpkg and domain-specific package
]] Michael Stapelberg
I am not familiar with the Ruby situation, I only know that many Ruby
developers seem to be very angry at Debian people. Is there a summary of
the events that I could read?
Debian's rubygems package installed gems to a directory not in $PATH,
meaning most documentation
Hi,
Am Mittwoch, den 30.01.2013, 16:52 +0800 schrieb Paul Wise:
On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
I would add one thing here: Haskell/GHC also (currently) doesn't create
shared libraries, and instead builds the program statically, but the
Debian Haskell group still tries
On Wed, Jan 30, 2013 at 04:52:33PM +0800, Paul Wise wrote:
On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
So, take this as an example of another language which doesn't do shared
linking but for which libraries are still packaged in Debian.
FWIW, OCaml is another such example.
Do all
On Wed, Jan 30, 2013 at 8:07 PM, Stefano Zacchiroli wrote:
On Wed, Jan 30, 2013 at 04:52:33PM +0800, Paul Wise wrote:
On Tue, Jan 29, 2013 at 7:55 PM, Iustin Pop wrote:
So, take this as an example of another language which doesn't do shared
linking but for which libraries are still packaged
On Wed, Jan 30, 2013 at 09:22:12AM +0100, Michael Stapelberg wrote:
3. Software packages from Apt cannot declare dependencies against
language-specific packages, for the same reasons highlighted in
#1.
Irrelevant argument in our case, as outlined earlier in the
discussion.
* Michael Stapelberg:
Hilko Bengen ben...@debian.org writes:
This is a pity for those of us who don't really subscribe to get
everything from github as needed model of distributing software.
Yes, but at the same time, it makes Go much more consistent across
multiple platforms.
Apparently,
* Wouter Verhelst:
On Tue, Jan 29, 2013 at 08:25:38AM +0100, Michael Stapelberg wrote:
Hi Hilko,
Hilko Bengen ben...@debian.org writes:
This is a pity for those of us who don't really subscribe to get
everything from github as needed model of distributing software.
Yes, but at the same
On Tue, 29 Jan 2013 22:57:03 +0100, Michael Stapelberg
stapelb...@debian.org wrote:
Wouter Verhelst wou...@debian.org writes:
consistency across multiple platforms has been claimed as a benefit
for allowing gem update --system to replace half of the ruby binary
package, amongst other things. It
Hi Hilko,
Hilko Bengen ben...@debian.org writes:
I drew a different conclusion from Ian's messages the thread you
mentioned (see the quotes below). Apparently, one *can* build shared
libraries using gccgo, but they are not currently usable using dlopen().
My impression was that this means
Marcelo wrote:
This situation gets so messy, that some Ruby developers prefer
to _not_ install ruby via dpkg at all. And they get mad when
something in the dependency chain pulls Ruby into the system.
To be fair, it's similar in reverse. Some Debian developers prefer to
_not_ install Ruby
On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre st...@einval.com
wrote:
To be fair, it's similar in reverse. Some Debian developers prefer to
_not_ install Ruby *at all*. Given how utterly awful the internals of
the language implementation are, I'd happily support dropping Ruby
from Debian
Paul Wise pabs at debian.org writes:
On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
Having multiple package managers which don't know about each other on a
system
is evil™ (but in some cases, can be managed properly).
Meh, it’s evil, period.
Some integration between dpkg and
Thorsten Glaser t...@debian.org writes:
My co-developer (on the MirBSD side) benz has written a script that
almost automates creation of a port (source package) from/for a CPAN:
http://www.slideshare.net/bsiegert/painless-perl-ports-with-cpan2port
(It looks even MacPorts has adopted it!)
Of
2013/1/30 Marc Haber mh+debian-de...@zugschlus.de:
On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre st...@einval.com
wrote:
To be fair, it's similar in reverse. Some Debian developers prefer to
_not_ install Ruby *at all*. Given how utterly awful the internals of
the language implementation
On Wed, Jan 30, 2013 at 09:16:59PM +, Thorsten Glaser wrote:
Meh, it’s evil, period.
Absolutely. As a user I have a nice package management system that I
know how to use and which works well. I don't need another one.
It is not the job of a language developer to invent yet another bloody
Lennart Sorensen lsore...@csclub.uwaterloo.ca writes:
Absolutely. As a user I have a nice package management system that I
know how to use and which works well. I don't need another one.
It is not the job of a language developer to invent yet another bloody
package distribution and
On 31/01/2013 05:16, Thorsten Glaser wrote:
On Wed, Jan 30, 2013 at 11:15 AM, Chow Loong Jin wrote:
Having multiple package managers which don't know about each other on a
system
is evil™ (but in some cases, can be managed properly).
Meh, it’s evil, period.
Well, really, the
On 30/01/2013 22:23, Игорь Пашев wrote:
2013/1/30 Marc Haber mh+debian-de...@zugschlus.de:
On Wed, 30 Jan 2013 16:25:12 +, Steve McIntyre st...@einval.com
wrote:
To be fair, it's similar in reverse. Some Debian developers prefer to
_not_ install Ruby *at all*. Given how utterly awful the
On Tue, Jan 29, 2013 at 08:25:38AM +0100, Michael Stapelberg wrote:
Hi Hilko,
Hilko Bengen ben...@debian.org writes:
This is a pity for those of us who don't really subscribe to get
everything from github as needed model of distributing software.
Yes, but at the same time, it makes Go
On Tue, Jan 29, 2013 at 09:44:43AM +0100, Wouter Verhelst wrote:
On Tue, Jan 29, 2013 at 08:25:38AM +0100, Michael Stapelberg wrote:
Hi Hilko,
Hilko Bengen ben...@debian.org writes:
This is a pity for those of us who don't really subscribe to get
everything from github as needed
Hi Wouter,
Wouter Verhelst wou...@debian.org writes:
consistency across multiple platforms has been claimed as a benefit
for allowing gem update --system to replace half of the ruby binary
package, amongst other things. It wasn't a good argument then, and it
isn't a good argument now.
I am
On 30/01/2013 05:57, Michael Stapelberg wrote:
I am not familiar with the Ruby situation, I only know that many Ruby
developers seem to be very angry at Debian people. Is there a summary of
the events that I could read?
I'm not very familiar with the situation myself, but the gist of it, as I
* Michael Stapelberg:
Go libraries (not binaries!) should be present in Debian _only_ for
the purpose of building Debian binary packages. They should not be
used directly for Go development¹.
This is a pity for those of us who don't really subscribe to get
everything from github as needed
Hi Hilko,
Hilko Bengen ben...@debian.org writes:
This is a pity for those of us who don't really subscribe to get
everything from github as needed model of distributing software.
Yes, but at the same time, it makes Go much more consistent across
multiple platforms. We should tackle one issue at
Hi,
I have been in contact with a few Go people and we have worked out the
following:
Go libraries (not binaries!) should be present in Debian _only_ for the
purpose of building Debian binary packages. They should not be used
directly for Go development¹.
Go library Debian packages such as
75 matches
Mail list logo
