Re: Ruby changes for Wheezy
At Fri, 4 Mar 2011 09:59:47 +0100, Lucas Nussbaum wrote: Lucas/Antonio, Thanks for all your good work, going through all mail thread and wiki, I have couple of questions. 1) All existing packages will be renamed or only new packages will be updated. 2) After renaming, package will be in experimental or unstable. -- Thanks Deepak http://wiki.debian.org/Teams/Ruby/RubyInWheezy Don't hesitate to ask for details if needed. - Lucas -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304085947.ga4...@xanadu.blop.info pgpZ9jUnNSUSU.pgp Description: PGP signature
Re: Ruby changes for Wheezy
On 28/03/11 at 14:08 +0530, Deepak Tripathi wrote: At Fri, 4 Mar 2011 09:59:47 +0100, Lucas Nussbaum wrote: Lucas/Antonio, Thanks for all your good work, going through all mail thread and wiki, I have couple of questions. 1) All existing packages will be renamed or only new packages will be updated. The goal is to have all binary packages renamed by the wheezy release. Since we will have only one binary package per source package, and our infrastructure generally deals better when the source package name is the same as the binary package name, we will also upload new source packages. 2) After renaming, package will be in experimental or unstable. I think that we can go for unstable now. The breakages should be minimal. Lucas -- 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/20110328091250.ga21...@xanadu.blop.info
Re: Ruby changes for Wheezy
On 09/03/11 at 22:27 +, Ian Jackson wrote: Lucas Nussbaum writes (Ruby changes for Wheezy): We are planning a rather large set of changes in Ruby packaging for Debian wheezy, and would appreciate some external feedback on our proposals. Our plans are described on http://wiki.debian.org/Teams/Ruby/RubyInWheezy Don't hesitate to ask for details if needed. I think your families of packages ruby1.8-foo ruby1.9.1-foo ruby-foo-common etc. are overcomplicated. Can you not find a way to make only one package for each extension, each containing an appropriate collection of .so files etc. ? what we could do, indeed, is ship all the .so files in the same binary package, and then hack the Depends field to have: ruby1.8 | ruby-interpreter What is the correct way to override what dpkg-shlibdeps detects? - Lucas -- 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/20110310104747.ga16...@xanadu.blop.info
Re: Ruby changes for Wheezy
On 2011-03-10, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: On 09/03/11 at 22:27 +, Ian Jackson wrote: Lucas Nussbaum writes (Ruby changes for Wheezy): We are planning a rather large set of changes in Ruby packaging for Debian wheezy, and would appreciate some external feedback on our proposals. Our plans are described on http://wiki.debian.org/Teams/Ruby/RubyInWheezy Don't hesitate to ask for details if needed. I think your families of packages ruby1.8-foo ruby1.9.1-foo ruby-foo-common etc. are overcomplicated. Can you not find a way to make only one package for each extension, each containing an appropriate collection of .so files etc. ? what we could do, indeed, is ship all the .so files in the same binary package, and then hack the Depends field to have: ruby1.8 | ruby-interpreter What is the correct way to override what dpkg-shlibdeps detects? you can override what dpkg-shlibdeps detect, but it sounds like you want to write your own shlibs/symbol files that tells ruby1.8 | ruby-interpreter for all involved libraries ? The last part of shlibs files is a free text file that is passed verbatim into the depends file. /Sune -- 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/slrninhfb1.rvp.nos...@sshway.ssh.pusling.com
Re: Ruby changes for Wheezy
On 10/03/11 at 12:00 +, Sune Vuorela wrote: On 2011-03-10, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: On 09/03/11 at 22:27 +, Ian Jackson wrote: Lucas Nussbaum writes (Ruby changes for Wheezy): We are planning a rather large set of changes in Ruby packaging for Debian wheezy, and would appreciate some external feedback on our proposals. Our plans are described on http://wiki.debian.org/Teams/Ruby/RubyInWheezy Don't hesitate to ask for details if needed. I think your families of packages ruby1.8-foo ruby1.9.1-foo ruby-foo-common etc. are overcomplicated. Can you not find a way to make only one package for each extension, each containing an appropriate collection of .so files etc. ? what we could do, indeed, is ship all the .so files in the same binary package, and then hack the Depends field to have: ruby1.8 | ruby-interpreter What is the correct way to override what dpkg-shlibdeps detects? you can override what dpkg-shlibdeps detect, but it sounds like you want to write your own shlibs/symbol files that tells ruby1.8 | ruby-interpreter for all involved libraries ? The last part of shlibs files is a free text file that is passed verbatim into the depends file. yes, but I also need to remove the part that says: libruby1.8, libruby1.9.1, librubinius, libjruby - Lucas -- 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/20110310121516.ga19...@xanadu.blop.info
Re: Ruby changes for Wheezy
On Thu, 10 Mar 2011, Lucas Nussbaum wrote:
What is the correct way to override what dpkg-shlibdeps detects?
Either you replace the dependency associated to the interpreters' libraries
by providing debian/shlibs.local (or any other file that you indicate with
-L) or you tell dpkg-shlibdeps to put the dependencies for the .so files
of interest in another variable like ${shlibs:Suggest} (mixing -d and -e
options as appropriate on the command line).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
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/20110310134227.ga2...@rivendell.home.ouaza.com
Re: Ruby changes for Wheezy
[Josselin Mouette, 2011-03-06]
Le samedi 05 mars 2011 à 00:22 +0100, Piotr Ożarowski a écrit :
Breaks: python (= 2.8), python ( 2.5)
yeah, that's to avoid bug reports when someone will try to use this
package with (default) python 2.4 or python 2.8 (which will NEVER be
released, BTW). dh_python2 will create similar dependencies to those
generated by dh_py{central,support} if Breaks: ${python:Breaks} is
missing in debian/control (I like Breaks because... that's what
Breaks is for)
You might “like” Breaks, but this:
Depends: python
Breaks: python (= 2.8), python ( 2.5)
has the same semantics as:
Depends: python (= 2.5), python ( 2.8)
Yes it does; if you will not add ${python:Breaks} in debian/control,
that's what dh_python2 will generate actually.
Packages with public modules do not really care about default Python
version usually so why should they depend on python package¹?
except that APT deals *much* better with Depends than it does with
Breaks.
What is the point of doing that?
Breaks will warn user if an upgrade of python can break some scripts with
/usr/bin/python in shebang, but python-foo packages can still be usable so
I prefer Breaks (because it's easier to override). If APT doesn't deal
well with Breaks, please report bugs against APT (with patches if
possible :)
[¹] if package ships .py files, there's a dependency on python package
due to pycompile/pyclean scripts, but if package is providing .so files
only, there's no need for python in Depends
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20110309150221.gf30...@piotro.eu
Re: Ruby changes for Wheezy
On Wed, 09 Mar 2011, Piotr Ożarowski wrote:
[Josselin Mouette, 2011-03-06]
You might “like” Breaks, but this:
Depends: python
Breaks: python (= 2.8), python ( 2.5)
has the same semantics as:
Depends: python (= 2.5), python ( 2.8)
Yes it does; if you will not add ${python:Breaks} in debian/control,
that's what dh_python2 will generate actually.
Having a different behaviour depending on whether a variable is listed in
a dependency or not does not look like good design to me.
Packages with public modules do not really care about default Python
version usually so why should they depend on python package¹?
[¹] if package ships .py files, there's a dependency on python package
due to pycompile/pyclean scripts, but if package is providing .so files
only, there's no need for python in Depends
This might be true but it smells like a useless optimization at the cost
of abusing the Breaks field. First of because you use it like IsBrokenBy
and then because Breaks is usually used to force the upgrade of the broken
package to a non-broken version. But you're not using it that way and I'm
not sure how well APT will cope with this.
What is the point of doing that?
Breaks will warn user if an upgrade of python can break some scripts with
/usr/bin/python in shebang, but python-foo packages can still be usable so
I prefer Breaks (because it's easier to override).
I really don't understand your point. If the default python is not
supported by python-foo, then it won't be coinstallable whether you're
using Depends or Breaks...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
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/20110309221828.gb27...@rivendell.home.ouaza.com
Re: Ruby changes for Wheezy
Lucas Nussbaum writes (Ruby changes for Wheezy): We are planning a rather large set of changes in Ruby packaging for Debian wheezy, and would appreciate some external feedback on our proposals. Our plans are described on http://wiki.debian.org/Teams/Ruby/RubyInWheezy Don't hesitate to ask for details if needed. I think your families of packages ruby1.8-foo ruby1.9.1-foo ruby-foo-common etc. are overcomplicated. Can you not find a way to make only one package for each extension, each containing an appropriate collection of .so files etc. ? Ian. -- 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/19831.65212.29089.76...@chiark.greenend.org.uk
Re: Ruby changes for Wheezy
Lucas Nussbaum lu...@lucas-nussbaum.net schrieb: That's what we plan to do: for now, ruby1.8 is the default implementation/version, and will have the highest priority in alternatives. So switching to say jruby would require manual intervention. Exactly that will ensure you run into a mess. Don't allow to switch the default interpreter or you will end up with dozens of bug reports due to people breaking their system. Such an idea neither works for java nor python nor tk/tcl nor ruby. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- 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/9172f657-a8bb-45f7-b7a3-f6ffaf6a0...@email.android.com
Re: Ruby changes for Wheezy
On 06/03/11 at 10:02 +0100, Bernd Zeimetz wrote: Lucas Nussbaum lu...@lucas-nussbaum.net schrieb: That's what we plan to do: for now, ruby1.8 is the default implementation/version, and will have the highest priority in alternatives. So switching to say jruby would require manual intervention. Exactly that will ensure you run into a mess. Don't allow to switch the default interpreter or you will end up with dozens of bug reports due to people breaking their system. Such an idea neither works for java nor python nor tk/tcl nor ruby. I prefer the situation where we empower users to make the switch if they decide to, to the situation where we arbitrarily decide that users should use Ruby 1.8 with no ability to change this (and get bug reports for that). Note that for the upstream Ruby developers, the stable branch is 1.9, not 1.8. - Lucas -- 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/20110306091038.ga6...@xanadu.blop.info
Re: Ruby changes for Wheezy
Le dimanche 06 mars 2011 à 10:10 +0100, Lucas Nussbaum a écrit : I prefer the situation where we empower users to make the switch if they decide to, to the situation where we arbitrarily decide that users should use Ruby 1.8 with no ability to change this (and get bug reports for that). Note that for the upstream Ruby developers, the stable branch is 1.9, not 1.8. You are just going to empower users to shoot themselves in the foot. You get to decide what the default version should be. If upstream thinks 1.9 is the stable branch, then you need to take appropriate steps to make it the stable branch. Another approach, which is used by Python packages too, is to create an alternate ruby-defaults version in experimental (or any other repository) that changes the default version. But this way it can be changed with the appropriate support in dependencies. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Ruby changes for Wheezy
Le samedi 05 mars 2011 à 00:22 +0100, Piotr Ożarowski a écrit :
Breaks: python (= 2.8), python ( 2.5)
yeah, that's to avoid bug reports when someone will try to use this
package with (default) python 2.4 or python 2.8 (which will NEVER be
released, BTW). dh_python2 will create similar dependencies to those
generated by dh_py{central,support} if Breaks: ${python:Breaks} is
missing in debian/control (I like Breaks because... that's what
Breaks is for)
You might “like” Breaks, but this:
Depends: python
Breaks: python (= 2.8), python ( 2.5)
has the same semantics as:
Depends: python (= 2.5), python ( 2.8)
except that APT deals *much* better with Depends than it does with
Breaks.
What is the point of doing that?
--
.''`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`-[…] I will see what I can do for you.” -- Jörg Schilling
signature.asc
Description: This is a digitally signed message part
Re: Ruby changes for Wheezy
On 06/03/11 at 10:43 +0100, Josselin Mouette wrote: Le dimanche 06 mars 2011 à 10:10 +0100, Lucas Nussbaum a écrit : I prefer the situation where we empower users to make the switch if they decide to, to the situation where we arbitrarily decide that users should use Ruby 1.8 with no ability to change this (and get bug reports for that). Note that for the upstream Ruby developers, the stable branch is 1.9, not 1.8. You are just going to empower users to shoot themselves in the foot. What if users want the ability to shoot themselves in the foot? Also, you seem to assume that Ruby 1.9 is completely broken. That's not true. A lot of things still work after switching from 1.8 to 1.9. Anyway. We are early in the wheezy release cycle. If switching ruby implementations using alternatives turns out to be a bad idea, we can switch back to the former approach at some point. And we will arguments to reply to users who currently want it. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548917 http://kangaroobox.blogspot.com/2009/12/switching-ruby-platforms-on-debian.html http://blog.alexn.org/2010/02/working-with-multiple-versions-of.html http://krnjevic.com/wp/?p=209 http://www.ruby-forum.com/topic/209014 http://fossplanet.com/f10/install-ruby1-9-1-a-96579/ https://bugs.launchpad.net/ubuntu/+source/ruby-defaults/+bug/634703 - Lucas -- 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/20110306095847.ga7...@xanadu.blop.info
Re: Ruby changes for Wheezy
On Sun, Mar 06, 2011 at 10:58:47AM +0100, Lucas Nussbaum wrote: On 06/03/11 at 10:43 +0100, Josselin Mouette wrote: Le dimanche 06 mars 2011 à 10:10 +0100, Lucas Nussbaum a écrit : I prefer the situation where we empower users to make the switch if they decide to, to the situation where we arbitrarily decide that users should use Ruby 1.8 with no ability to change this (and get bug reports for that). Note that for the upstream Ruby developers, the stable branch is 1.9, not 1.8. You are just going to empower users to shoot themselves in the foot. What if users want the ability to shoot themselves in the foot? They already have, with dpkg-divert. Why add another one? Mike -- 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/20110306102109.gb5...@glandium.org
Re: Ruby changes for Wheezy
Le dimanche 06 mars 2011 à 10:58 +0100, Lucas Nussbaum a écrit : You are just going to empower users to shoot themselves in the foot. What if users want the ability to shoot themselves in the foot? Currently you’re the one holding the weapon. Also, you seem to assume that Ruby 1.9 is completely broken. That's not true. A lot of things still work after switching from 1.8 to 1.9. I don’t know whether Ruby 1.9 is broken or not. What I’m sure of, is that with your proposed dependency scheme, you will not be able to ensure dependencies will be installed for Ruby 1.9. Which means changing the Ruby version with alternatives would just break user systems. If users want Ruby 1.9, serve them Ruby 1.9 and get rid of the applications not supporting it (or use explicit versions for them). But don’t serve them a system that is half-compatible with Ruby 1.9 and not up to the stability expectations of a Debian system. If you choose to support several Ruby interpreters through alternatives, you have to specify the interface that /usr/bin/ruby provides, just like for Java. This means settling on the lowest common denominator of what these interpreters can provide - and this is *completely opposite* to the users’ request, since they want to benefit from the improvements in Ruby 1.9. Anyway. We are early in the wheezy release cycle. If switching ruby implementations using alternatives turns out to be a bad idea, we can switch back to the former approach at some point. And we will arguments to reply to users who currently want it. Do you really need to break hundreds of user systems just to make a handful of whiners happy? See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548917 Proposes a wrong solution without explaining why you’d want to do that - and really, it is stupid. http://kangaroobox.blogspot.com/2009/12/switching-ruby-platforms-on-debian.html http://blog.alexn.org/2010/02/working-with-multiple-versions-of.html http://krnjevic.com/wp/?p=209 These three explain how to break your system. There are thousands of such half-assed “documents”, and we receive many bug reports of users breaking their systems after that. A few days ago, a user complained that his gnome-panel was broken. It turned out he had applied a procedure to install mysql-workbench which just broke his GLib. http://www.ruby-forum.com/topic/209014 http://fossplanet.com/f10/install-ruby1-9-1-a-96579/ They are just asking for 1.9. Alternatives is the wrong answer to the users’ problem. https://bugs.launchpad.net/ubuntu/+source/ruby-defaults/+bug/634703 If we just applied all user suggestions when they come up, do you know how much buggy Debian would be? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Ruby changes for Wheezy
On 06/03/11 at 11:22 +0100, Josselin Mouette wrote: Le dimanche 06 mars 2011 à 10:58 +0100, Lucas Nussbaum a écrit : You are just going to empower users to shoot themselves in the foot. What if users want the ability to shoot themselves in the foot? Currently you’re the one holding the weapon. Also, you seem to assume that Ruby 1.9 is completely broken. That's not true. A lot of things still work after switching from 1.8 to 1.9. I don’t know whether Ruby 1.9 is broken or not. What I’m sure of, is that with your proposed dependency scheme, you will not be able to ensure dependencies will be installed for Ruby 1.9. Which means changing the Ruby version with alternatives would just break user systems. If users want Ruby 1.9, serve them Ruby 1.9 and get rid of the applications not supporting it (or use explicit versions for them). But don’t serve them a system that is half-compatible with Ruby 1.9 and not up to the stability expectations of a Debian system. If you choose to support several Ruby interpreters through alternatives, you have to specify the interface that /usr/bin/ruby provides, just like for Java. This means settling on the lowest common denominator of what these interpreters can provide - and this is *completely opposite* to the users’ request, since they want to benefit from the improvements in Ruby 1.9. Note that, for applications written in Ruby and packaged in Debian, we will make sure that they work no matter what /usr/bin/ruby points to (if necessary, by forcing the shebang to ruby1.8, and installing the correct dependencies). What might break is software manually installed by users. I don't see how that situation is different from the Java one. Anyway. We are early in the wheezy release cycle. If switching ruby implementations using alternatives turns out to be a bad idea, we can switch back to the former approach at some point. And we will arguments to reply to users who currently want it. Do you really need to break hundreds of user systems just to make a handful of whiners happy? I am under the impression that it's not a handful of whiners, but that the consensus in the Ruby community is that we should switch to alternatives. - Lucas -- 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/20110306104001.ga8...@xanadu.blop.info
Re: Ruby changes for Wheezy
Le dimanche 06 mars 2011 à 11:40 +0100, Lucas Nussbaum a écrit : Note that, for applications written in Ruby and packaged in Debian, we will make sure that they work no matter what /usr/bin/ruby points to (if necessary, by forcing the shebang to ruby1.8, and installing the correct dependencies). What might break is software manually installed by users. I don't see how that situation is different from the Java one. Except that for Java, there’s a clear specification of what a JVM should provide - and it’s already insanely complex. If you manage to get everything working with both ruby1.8 and ruby1.9, this looks like a great deal of work for nothing; if everything can work with 1.9, just ship it as default and get done with it. Do you really need to break hundreds of user systems just to make a handful of whiners happy? I am under the impression that it's not a handful of whiners, but that the consensus in the Ruby community is that we should switch to alternatives. It looks to me that “the Ruby community” doesn’t understand what alternatives are nor what they were designed for. You need to understand what the real needs of your users are and provide them with a proper solution according to our standards. Just because some people heard of this alternative thing doesn’t mean it is a suitable solution for Debian. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Ruby changes for Wheezy
OoO En cette fin de matinée radieuse du dimanche 06 mars 2011, vers 11:40, Lucas Nussbaum lu...@lucas-nussbaum.net disait : Note that, for applications written in Ruby and packaged in Debian, we will make sure that they work no matter what /usr/bin/ruby points to (if necessary, by forcing the shebang to ruby1.8, and installing the correct dependencies). What might break is software manually installed by users. I don't see how that situation is different from the Java one. This is also what is done with Python. We get very little complaints with this. However, maybe the Python roadmap is easier to understand and less applications get broken when upgrading to a new major version. Breaking applications that are installed outside of the package manager is bad but it is far less worse than breaking applications installed with the package manager. Anyway. We are early in the wheezy release cycle. If switching ruby implementations using alternatives turns out to be a bad idea, we can switch back to the former approach at some point. And we will arguments to reply to users who currently want it. Do you really need to break hundreds of user systems just to make a handful of whiners happy? I am under the impression that it's not a handful of whiners, but that the consensus in the Ruby community is that we should switch to alternatives. Do they really understand that alternatives may break a lot of things on user systems? By reading your blog, I understand that the Ruby community (or a part of it) does not really understand that Debian does want to provide a robust way to manage applications. If the user install software X written in Ruby with apt, then uses update-alternatives to switch Ruby version and then software X is broken, it seems we are to blame because using update-alternatives should not break installed softwares. -- Program defensively. - The Elements of Programming Style (Kernighan Plauger) pgp0oKAcTMtOH.pgp Description: PGP signature
Ruby changes for Wheezy
Hi, We are planning a rather large set of changes in Ruby packaging for Debian wheezy, and would appreciate some external feedback on our proposals. Our plans are described on http://wiki.debian.org/Teams/Ruby/RubyInWheezy Don't hesitate to ask for details if needed. - Lucas -- 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/20110304085947.ga4...@xanadu.blop.info
Re: Ruby changes for Wheezy
On Mar 04, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: Our plans are described on http://wiki.debian.org/Teams/Ruby/RubyInWheezy Don't hesitate to ask for details if needed. Is this acceptable to the major Ruby developers or do they still hate you and everybody else involved? -- ciao, Marco signature.asc Description: Digital signature
Re: Ruby changes for Wheezy
On 04/03/11 at 10:58 +0100, Marco d'Itri wrote: On Mar 04, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: Our plans are described on http://wiki.debian.org/Teams/Ruby/RubyInWheezy Don't hesitate to ask for details if needed. Is this acceptable to the major Ruby developers or do they still hate you and everybody else involved? The major Ruby developers are generally OK, since they mostly come from a Unix background. it's the second circle that hates us. We haven't asked them yet about those changes. It is planned, but we thought that it would be better to ask more friendly and welcoming audiences like debian-devel@ first;) - Lucas -- 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/20110304100357.ga30...@xanadu.blop.info
Re: Ruby changes for Wheezy
On 2011-03-04, Stefano Zacchiroli z...@debian.org wrote: === Generation of ri and rdoc documentation === We decide not to generate the ri and rdoc documentation, as there are good online services providing it (like rdoc.info). We might change our mind later. :) Are you sure about that? Not that I do much Ruby nowadays, but for other languages I find it incredibly helpful that there are actually useful doc packages for the times when I'm disconnected from the net (longer train sessions, lodges without internet access). Back then ri was a very nice tool to lookup most functions you need. Kind regards Philipp Kern -- 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/slrnin1glp.tkl.tr...@kelgar.0x539.de
Re: Ruby changes for Wheezy
Philipp Kern tr...@philkern.de writes: On 2011-03-04, Stefano Zacchiroli z...@debian.org wrote: === Generation of ri and rdoc documentation === We decide not to generate the ri and rdoc documentation, as there are good online services providing it (like rdoc.info). We might change our mind later. :) Are you sure about that? Not that I do much Ruby nowadays, but for other languages I find it incredibly helpful that there are actually useful doc packages for the times when I'm disconnected from the net (longer train sessions, lodges without internet access). Back then ri was a very nice tool to lookup most functions you need. If ri and rdoc generation is handled by a post install hook, this hook can check a local configuration variable to generate documentation, or silently exit. -- Stig Sandbeck Mathisen s...@debian.org -- 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/7xbp1r5bef@fsck.linpro.no
Re: Ruby changes for Wheezy
Le vendredi 04 mars 2011 à 11:16 +0100, Stefano Zacchiroli a écrit : === Use alternatives to switch between Ruby implementations === There is a huge demand (see [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548917|#548917]]) for using alternatives to switch between Ruby implementations. This would provide a way to mimic what RVM provides in a cleaner way, and will help the Ruby community with moving to 1.9.x or other implementations. I think this would be asking for a disaster. A given version of the distribution should provide a given version of /usr/bin/ruby. Otherwise you’re just going to see third-party software (and often Debian packages) break in horrible ways. Let’s say for example that a script has a #!/usr/bin/ruby shebang, and uses the foo module. The package Depends: ruby, ruby-foo. In turn, this will pull ruby1.8-foo. Now let’s say someone installs it and then installs ruby1.9.1, and selects it as the default ruby version. Now ruby1.9.1-foo is not installed and you’re doomed. In short: just because many people ask for it doesn’t mean it’s a good idea. * pure-ruby libs must produce a single binary package named '''ruby-foo''' * libraries with both pure-Ruby and native code must be handled like this: [snip] Looks correct to me, but it would probably be easier to do like with Python: put everything in a single package, de-duplicating data between versions. This way transitions are much smoother. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1299243623.404.108.camel@meh
Re: Ruby changes for Wheezy
On 04/03/11 at 14:00 +0100, Josselin Mouette wrote: Le vendredi 04 mars 2011 à 11:16 +0100, Stefano Zacchiroli a écrit : === Use alternatives to switch between Ruby implementations === There is a huge demand (see [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548917|#548917]]) for using alternatives to switch between Ruby implementations. This would provide a way to mimic what RVM provides in a cleaner way, and will help the Ruby community with moving to 1.9.x or other implementations. I think this would be asking for a disaster. A given version of the distribution should provide a given version of /usr/bin/ruby. Otherwise you’re just going to see third-party software (and often Debian packages) break in horrible ways. Let’s say for example that a script has a #!/usr/bin/ruby shebang, and uses the foo module. The package Depends: ruby, ruby-foo. In turn, this will pull ruby1.8-foo. Now let’s say someone installs it and then installs ruby1.9.1, and selects it as the default ruby version. Now ruby1.9.1-foo is not installed and you’re doomed. In short: just because many people ask for it doesn’t mean it’s a good idea. Yeah, I know. But I think that we should do what is best for our users, even if it looks shockingly dangerous from our POV. Also, while we will provide the capability to switch between ruby versions using alternatives, it will be advertised that if you do that, it's your job to install additional dependencies. * pure-ruby libs must produce a single binary package named '''ruby-foo''' * libraries with both pure-Ruby and native code must be handled like this: [snip] Looks correct to me, but it would probably be easier to do like with Python: put everything in a single package, de-duplicating data between versions. This way transitions are much smoother. Sorry, could you explain how it works in python, when a given binary package contains stuff for both python 2.6 and 2.7, for example? How do you manage the Depends: line? (Pointing me to a good example would work, too) - Lucas -- 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/20110304131634.ga4...@xanadu.blop.info
Re: Ruby changes for Wheezy
On 03/04/2011 02:00 PM, Josselin Mouette wrote: Le vendredi 04 mars 2011 à 11:16 +0100, Stefano Zacchiroli a écrit : === Use alternatives to switch between Ruby implementations === There is a huge demand (see [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548917|#548917]]) for using alternatives to switch between Ruby implementations. This would provide a way to mimic what RVM provides in a cleaner way, and will help the Ruby community with moving to 1.9.x or other implementations. I think this would be asking for a disaster. A given version of the distribution should provide a given version of /usr/bin/ruby. Otherwise you’re just going to see third-party software (and often Debian packages) break in horrible ways. Indeed. You would want to define a default version and some 'supported' (but non-default) other versions. Again my recommendation - look at the way how these things are handled in Python (yeah, ignore the discussions around varoius Python helpers and so on). -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4d70e872.2000...@bzed.de
Re: Ruby changes for Wheezy
On 04/03/11 at 14:26 +0100, Bernd Zeimetz wrote: On 03/04/2011 02:00 PM, Josselin Mouette wrote: Le vendredi 04 mars 2011 à 11:16 +0100, Stefano Zacchiroli a écrit : === Use alternatives to switch between Ruby implementations === There is a huge demand (see [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548917|#548917]]) for using alternatives to switch between Ruby implementations. This would provide a way to mimic what RVM provides in a cleaner way, and will help the Ruby community with moving to 1.9.x or other implementations. I think this would be asking for a disaster. A given version of the distribution should provide a given version of /usr/bin/ruby. Otherwise you’re just going to see third-party software (and often Debian packages) break in horrible ways. Indeed. You would want to define a default version and some 'supported' (but non-default) other versions. Again my recommendation - look at the way how these things are handled in Python (yeah, ignore the discussions around varoius Python helpers and so on). That's what we plan to do: for now, ruby1.8 is the default implementation/version, and will have the highest priority in alternatives. So switching to say jruby would require manual intervention. - Lucas -- 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/20110304133101.ga5...@xanadu.blop.info
Re: Ruby changes for Wheezy
On Fri, Mar 04, 2011 at 02:26:10PM +0100, Bernd Zeimetz wrote: On 03/04/2011 02:00 PM, Josselin Mouette wrote: Le vendredi 04 mars 2011 à 11:16 +0100, Stefano Zacchiroli a écrit : === Use alternatives to switch between Ruby implementations === There is a huge demand (see [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548917|#548917]]) for using alternatives to switch between Ruby implementations. This would provide a way to mimic what RVM provides in a cleaner way, and will help the Ruby community with moving to 1.9.x or other implementations. I think this would be asking for a disaster. A given version of the distribution should provide a given version of /usr/bin/ruby. Otherwise you’re just going to see third-party software (and often Debian packages) break in horrible ways. Indeed. You would want to define a default version and some 'supported' (but non-default) other versions. Again my recommendation - look at the way how these things are handled in Python (yeah, ignore the discussions around varoius Python helpers and so on). +1 this is exactly the reason why we adopted *one* default Tcl/Tk instead of the broken-by-design use of admin-changeable alternatives. Interpreters are not the right target for such an approach. We have to choose a safe default version and provides optionally other versions with strict dependencies used only when required. -- Francesco P. Lovergine -- 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/20110304141642.gd3...@gandalf.is-a-geek.org
Re: Ruby changes for Wheezy
Heyho! On Friday 04 March 2011 14.16:34 Lucas Nussbaum wrote: Sorry, could you explain how it works in python, when a given binary package contains stuff for both python 2.6 and 2.7, for example? I'm not involved with Python packages, so somebody correct me please. The way it's done is that the packages declare what versions of python they support: python-pygments, for example: Depends: python2.6 | python2.7 | python2.5, python (= 2.6.6-7~) Breaks: python (= 2.8), python ( 2.5) (these are generated by helpers - I'm not 100% why the Breaks is necessary, but I think it's to ensure that any given python library is available in all supported python versions that are installed. A way without that would be nice though, even if that would mean python2.8 wouldn't see all modules that are installed. OTOH this would certainly generate lots of mails to the bts by users...) Then, via triggers, the module is compiled to bytecode for all supported python versions, added to the version's module path etc. (not sure how exactly this is done, and I guess this would be different for ruby in any case.) Modules with binary parts usually just deliver the shared libraries in the main python-foo package (see python-yenc), but I guess it is possible to create python2.5-foo and python2.6-foo and have both provide the virtual python-foo. Don't know if it exists. cheers -- vbi -- Whenever people agree with me, I always think I must be wrong. -- Oscar Wilde signature.asc Description: This is a digitally signed message part.
Re: Ruby changes for Wheezy
[Adrian von Bidder, 2011-03-04]
The way it's done is that the packages declare what versions of python they
support:
python-pygments, for example:
python-pygments uses dh_python2 which takes a little bit different
approach than dh_pycentral or dh_pysupport.
dh_python2 ships all symlinks in the .deb package, in contrast to other
two tools which create them at install time (package's or interpreter's
install time). That means if package doesn't provide extensions,
dh_pysupport and dh_pycentral packages do not need another upload if new
Python version is added to the list of supported Python versions.
All tools byte-compile these files at install time (.pyc or .pyo files
are not shipped in .debs) for all installed Python versions that are
supported by the package.
Depends: python2.6 | python2.7 | python2.5, python (= 2.6.6-7~)
python2.6 is first because it's the default Python version, after the
default Python version (if package supports it) all other supported
(by the .deb) Python versions are listed (from newest to oldest)
python (= 2.6.6-7~) is here due to pycompile/pyclean scripts used in
maintainer scripts
Breaks: python (= 2.8), python ( 2.5)
yeah, that's to avoid bug reports when someone will try to use this
package with (default) python 2.4 or python 2.8 (which will NEVER be
released, BTW). dh_python2 will create similar dependencies to those
generated by dh_py{central,support} if Breaks: ${python:Breaks} is
missing in debian/control (I like Breaks because... that's what
Breaks is for)
Then, via triggers, the module is compiled to bytecode for all supported
dh_pysupport byte-compiles them via triggers, dh_pycentral and
dh_python2 byte-compile them in postinst (and remove .pyc files in
prerm)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20110304232230.gv30...@piotro.eu
