 Ok, merci. Donc, bienvenue à cette présentation à DeppConf. C'est ce que j'ai interprété en bas. Avant de commencer, j'aimerais savoir qui est déjà développé en Ruby ou en gardant les packages Ruby. Ok, merci. Donc, j'ai beaucoup de slides pour en bas. Cela servira pour l'introduction. Et ensuite, nous pouvons discuter sur les choses. Donc, Ruby est une langue scriptée qui m'a aidé à résoudre des problèmes similaires à Pearl et Python. Donc, on peut généralement utiliser Ruby plutôt que Pearl ou Python. C'est à la même âge que Python, qui a l'air un peu étrange parce que c'est plus populaire que Python. Probablement, le fait que c'est commencé en Japon qui était assez confidentiel au-delà de Japon pendant un temps, n'a pas aidé à obtenir le même niveau de popularité que Python. Donc, Ruby est très populaire dans les applications web et les cloud, qui sont des zones où Debian n'est pas très populaire, qui probablement le rend plus populaire d'une perspective de Debian. C'est aussi très populaire dans ces admin-circles avec des outils comme Puppet et Chef qui sont rétendus dans Ruby, qui sont les principaux utilisateurs de Ruby au-delà des applications web. Donc, c'est au-delà de ne pas hésiter à demander des questions dans le milieu si tu désagris avec quelque chose ou si tu veux commenter quelque chose. Donc, nous allons regarder les features de Ruby. Donc, c'est une langue qui a été développée par l'inspiration par d'autres langues. C'est pas développé par quelqu'un qui pense qu'il sait la façon qu'il devrait être sans qu'il regarde d'autre côté. C'est très inspiré par Pearl, Smalltalk et Lisp. Donc, par exemple, la communauté Smalltalk est généralement très proche de sa langue. Mais quand tu parles à Smalltalk, à Smalltalk's fans, tu leur dis à Ruby par exemple, c'est très bon, c'est comme Smalltalk mais avec un meilleur syntaxe. Donc, c'est très bon de voir que certaines personnes de la communauté Smalltalk qui est considérée assez pure d'une langue objectif adoptée à Ruby. Donc, Ruby est très objectif. C'est inspiré par des langues fonctionnelles et elle t'emmène d'avoir un syntaxe de l'exemple qui est pas très simple. Mais il y a beaucoup de choses. Donc, imagine qu'il y a un array ou un liste d'objets appelés bugs. Et les objets ont des messages comme la sévélité. Dans Ruby, tu peux faire quelque chose comme ça. Tu peux faire des bugs de la sélection de la sélection passée à un bloc qui est similaire d'un lambda en personne. Donc, pour chaque objectif tu calls tu check si la sévélité est sérieuse. Et puis, tu as un autre liste comme résultat et avec seulement les bugs c'est la sévélité sérieuse. Et puis, tu peux faire un autre filtre pour réjecter les bugs où le nom de package est un de les packages pseudo c'est un autre liste, d'exemple. Et puis, tu peux avoir un liste comme résultat avec seulement les vrais bugs et puis, tu peux réorganiser le liste en groupant par le nom de package source. Donc, tu as un hash où chaque valeur est un liste de bugs. Donc, tu peux faire ça dans 3 lines parce que la première ligne est assez longue. Mais un autre feature de Ruby est que généralement, tu n'as pas 4 ou des iteratrices tu vas juste utiliser des méthodes comme chaque. Donc, par exemple, tu peux utiliser un liste et faire le nom de liste et pour chaque valeur dans cette liste tu exécutes un bloc. Donc, tu as toujours iteré d'autres objets qui sont très différents pour faire un 1 2 10 et faire quelque chose. Donc, c'est vraiment confortable d'avoir des codes en Ruby. Et souvent, c'est facile d'avoir des codes à lire. Quand tu sais qu'il y a des tags de Ruby, c'est assez facile de lire à gauche et à droite. Donc, ce sont les features de Ruby. Maintenant, je vais parler des features anti-Ruby. C'est un peu plus léger. Donc, il y a plusieurs choses suboptimales dans Ruby. La première, c'est la communauté de développement. Donc, c'est principalement qui ordinate du Japon et currently, il y a 2 développements en liste. Donc, Ruby Core, en anglais et Ruby Dev, en japonais. C'est bien. Mais, beaucoup de discussions sont en Ruby Dev. Donc, si vous n'avez pas des Japonais, vous n'aurez pas de Japonais, vous ne pouvez pas influencer les processus. Donc, toutes les décisions sont annoncées sur Ruby Core, mais souvent, c'est trop tard pour changer ce qui s'est passé. C'est un peu léger, surtout quand parfois, vous avez des reports de bug, vous trouvez des reports de bug, vous savez que c'est le problème que vous avez, mais tout est en Japonais. Donc, c'est assez difficile d'understand ce qu'est le problème Je ne suis pas sûr, je me suis demandé si l'objectif camel était en train de faire la même chose ou pas, vous savez. Il y a l'objectif camel en français, pour les développeurs. C'est anglais, seulement anglais. Ok. Un autre problème avec Ruby c'est le management de release. Donc, il y a currently several branches qui sont activement développées. Donc, il y a 1.8 branches qui sont l'ancienne version, l'ancienne implementation de Ruby. Donc, une question est si il y a un Ruby 1.8.8, l'ancienne version 1.8.7. C'est probable qu'il n'y ait pas une nouvelle version de 1.8. C'est la référence pour le bug si vous voulez vérifier la discussion. Mais c'est pas complètement sûr que ça ne va pas arriver. En même temps, il y a plusieurs branches de développement. Donc, il y a 192, ce qui est l'ancienne branches de stabilisation. Mais il y a un peu moins d'adoption comparé à 1.8. Donc, les développeurs d'optimisation disent que les gens devraient utiliser ça et les gens devraient utiliser ça. Il y a aussi 193, ce qui était juste un branch de tronc deux semaines auparavant, ce qui est la prochaine release de stabilisation. Et il y a un tronc qui est un branch d'adoption. Donc, working with four different branches can be fine. The problem is that there's clearly a manpower problem. And for example, there are many bugs that are only fixed in two of those branches. For example, there was recently a security issue in Ruby. It was fixed in 1.8 and tronc. Well, and that was before 193 was branch of tronc. But they released a new version of 192 without fixing the security issue. So you really need to check what they are doing. It's really hard. Another thing related to that is that usually they don't support all of the architecture that they're going to support, is supporting. They mainly support AMD64 and i386. Beside that, we are on our own, basically. And when we report issues about other developing architecture, they don't really care. So we have to fix them ourselves, which might not always be easy. Another issue with the Ruby community is the advocacy of developer-only tools for everybody. So one big, one tool that's a lot of hype in the Ruby community is RVM. So RVM is a bash script that can check out using Git snapshot of the interpreter and build it locally and install it locally. And then you can switch between several implementations of the interpreter on your own machine. So that's really great for developers who want to use the latest version of Ruby. But not so great for CIS admins who are required to install that by their developers. And another tool is RubyGems which is a Ruby-specific package manager. For those of you who know Python, it's similar to Python X. So it's a really, really great tool for developers because it enables developers to get the latest version of a given package. And it makes it really easy to distribute packages in a quite clean way. So there are many small Ruby packages because of that because it's really that simple to release 100 red lines package. But then the Ruby community seems to think that that's the only way that Ruby software should be distributed and so there's quite a lot of tension between that and the beyond packages. So one common opinion in the Ruby community is that packages are useless and people should just use RBM and RubyGems. So it's quite hard to well one can feel demotivated about that. So if you want a long version of this for the blog post that I wrote back in January when I actually decided to stop doing Ruby stuff and then the discussion was quite interesting and I changed my mind. I didn't quite like to do that but well I decided to continue. Any comments questions? No. So Ruby in Debian is maintained by two teams. So the first one is PKG Ruby which maintains the interpreters. That's Ruby 1.8 and Ruby 1.9.1. So that's Akira, Daigo and me. And by the second team which called PKG Ruby Extras which maintains all the Ruby libraries well which maintains Ruby libraries and applications not necessarily all of them. So on alias there are 29 members listed. There's quite a lot of GDs also members of the team but most of them are quite inactive or are really well don't really aren't very active. So the ones that are the most active are well Vincent Formon is quite active Andres is quite active mostly on his packages me Gunnar is quite active and Antonio Tessillo is was just just became a GD like three weeks ago and that's a lot of great work. I hope that he will continue. If he is listening please don't leave the team because it would be really hard for the team. And there are also quite a lot of people maintaining Ruby packages outside the team. So as usual in Debian the two teams are largely understaffed which is probably the case everywhere and if you want to join as a pointer so the team documentation is quite good I improved it just before Debconf That's mainly that we use for discussion and that's the ISE channel that we use for discussion So I'm going to talk a bit about the relationship between Debian and the Ruby community so going back to the anti-features So as I said before there's quite a lot of tensions with some members of the Ruby community saying that what we do is useless basically So during the recent months after I decided to continue doing a Ruby packaging we fixed quite a lot of issues which were not really which we didn't consider as problems but the Ruby community considered as problems So for example we at some point in the past like five or six years ago the standard library was split into several packages and we had like 15 packages for the worst in the library it improved so gradually over time we reduced the number of packages and currently that's the packages that built from the Ruby 1.8 Ruby 1.8 source So if you install this and this we have all the standard library except LibTCLTK which is not something that most people need anyway To make people happy we also added Ruby 1.8 that's full package that just depends on all of them that way it's easy for people to say just install Ruby 1.8 that's full and they got everything Another thing that would change recently is that now you can switch between Ruby implementations using the update alternative system So you can if you want to use so the default in Debian is still 1.8 but if you want to try 1.9 you can just use update alternatives to change to 1.9 then all your apps will run with 1.9 So this is about it has the same level of support as for Java which means that it might break not everything completely works with 1.9 but we hope that most of it is covered we will show later or we ensure that Another thing that would change recently is that now when you install a gem the executable files that are installed by the gem no land in user local bin which means that it's in pass and it's executable It was on the case before which was a huge source of tension with the Ruby community and gem update dash dash system was re-enabled but you have to so what that does is that it updates Ruby gems itself so it replaced what you installed with app with something that is downloaded from the internet so it's it's probably well it's a bit strange to have that in a Debian system but since everybody complains and you have to make your user happy it's probably better to have it working than well you have to set an environment variable to say that you are really sure that you want to do that before it happens on a reasonable compromise so with all those changes I think that there's no the Ruby community doesn't have anything to complain about Debian anymore because we implemented basically what they wanted but well some people still whine and consider Debian and Ubuntu as completely obsolete and crippling Ruby but well you can't make everybody happy so now I'm going to talk about Gem2Deb which is our new new packaging framework so in the past we were using a CDBS based helper it was called it was in the package RubyPKGTools so we moved since a few months ago to Gem2Deb so what Gem2Deb does it takes a gem turn it into a Debian source package and then into a Debian source package so it generates rather clean Debian source package so to compare it to what other teams do it does both DH DH Make Perl part so there's a DH Make Ruby and DH Perl which is used during the build process which is replaced by DH Ruby so it's DH based it tries to do almost everything automatically and it helps to support several Ruby implementations it means that we build packages both for 1.8 and 1.9 and run the test shoots both for 1.8 and 1.9 we use a single binary package which is called Ruby-foo with foo being the gem name that's really interesting because it means that we can easily add another Ruby implementation without having to introduce an additional binary package which was the case before when we were using leap foo that should be 1.8 or leap foo that should be 1.9 so we run test shoots after the build and the implementation is so it's both a DH build system and a sequence which is just a technical DH stuff and it's about 50 lines of Perl and the rest of it is Ruby so all the important stuff is in Ruby so I will does someone has questions about this or comments or discussion will be short I will just do a demo of this if it works yeah yeah that's good probably I can or maybe I will I think Magnum terminal I think that usually works better so let's say okay oh, before doing the demo we just talk about transition so so we want to transition to gem to deb for all packages in Debian so each package currently in Debian must be migrated to gem to deb so that's ideal line of progress that's a date of with freeze and so we are looking quite bad currently it's not that bad because quite a lot of packages can be removed we have quite a lot of all Ruby gems that are not really used that we could remove instead of migrating to gem to deb that's a bit faster than migrating them so help is very welcome to do to work on that and another good point about Ruby gems is that on rubygems.org which is a central hub where all gems can be found there's a list of what sort of popularity contest about gems so we know what is important to package and what is not so important to package so that's the web page these things current status of the transition so you just have lots of packages and let's try to migrate completely randomly chosen SQL line 3 dash ruby so to migrate it I need network I have a backup plan let's try to do it with the network ok, let's switch to the backup plan so let's say that I could gem fetch that gem yeah so I could normally do that and that would work in that case since I can't download it I will use the local copy so when I do that I will restart can you still read the screen it's fine probably so what it does is that it creates a source tab all from the gem so it extracts the gem and builds a TGZ from it which means that you can also start from a TGZ if your ruby library is not provided as a gem you can just start with the TGZ it also works so you start with this then it creates a source package from that TGZ and then it builds the package so the goal is to have the tools that can be used by Debian maintainers to create source package but also by Debian users to generate depths that are quite okay to use internally they are not when you just do gem to debonit it doesn't produce gems depths that you can use that you can upload to Debian with depth that you can probably use internally so it just does everything and so it builds the extension for 1.8 builds the extension for 1.9 and then it fails because it can't run the test because of that so it can't find the helper file we just continue building to so in that case it built a source package confirm using the version 3quilt source format and the depth there identically because they have to run it here so it just generates all files based on what is in the gem for example if I look at control it uses gem description here to fill in the description field so it needs to be edited but it's still a good basis for to start from there it also adds as a comment the dependencies that were listed in the gem so even if probably it's not completely true but it's still a good basis so I'm going to fix test start failings so what it does also is that there are two ways to run tests the first one is to just list the test files that are also provided in the gem usually so just a gemfile with a list of test files and that doesn't work in that case because as I use as I use it requires helper well it should be test slash helper so I could just fix them all and it would work the easier way is to use the other way of running tests with gem to deb which is to add rubytests.rb file in the debian there so I will remove that one and edit that one so I just need so this just says that I will load a file in the spec or test there and that's usually enough except that in my case I need to add a test to the load path so that it finds the helper file so building the extensions and then it runs the test for 1.8 it runs the test for 1.9 and it worked ok so with that I get quite working quite clean source package with minimal work so the last thing to do is we want to transition from this package so we have to add transitional packages for those packages that's that's the source package to the binary packages so we need to override them and I can do that like that so there's a script called genrubytrans packages that just generates control file snippet that you need and then I just need to to copy paste this that's for the package that is being replaced and that's the transitional package so with that I get my clean package with all the transitional packages with the correct version etc any questions about that ? wait for the microphone you said you are trying to support gem.app for internal users now we have some applications and each application uses a different gem set so we would need to have multiple versions of the same gem in our repositories do you have a solution for that ? no the way it is solved by RubyGems itself is really ugly and I think that one thing that we need to force app3m to do is to maintain some level of compatibility and we can't support many versions of the same gem and it's just crazy it works like that I think it's improving less and less problems about that in the Ruby community do you have an example of applications that require specific versions of gems ? un exemple c'est la gem de JSON il y a des libraries qui dépendent de JSON plus de 1.5 qui dépendent de JSON plus de 1.5 donc il y a des problèmes je pense que pour cet exemple la seule solution c'est de force les gens à migrer pour la nouvelle version parce que nous ne pouvons pas entendre que c'est ça d'ailleurs mais pour nous, nous sommes réellement achetés par l'application interne pour qu'on peut installer les applications parallèles pour le moment je pense que ces migrations les modèles les développeurs de Ruby tentent d'attendre que le système de packaging de gem est important pour soutenir la partie du combat que le Lucas a fait c'est que nous ne pouvons pas faire ça pour nous faire ce genre de migration je pense que c'est possible d'autres recommandations ? il y a juste un slide je pense d'autres choses qui se passent dans le monde de Ruby c'est qu'on a de nouveaux modèles pour la packaging maintenant on a 192 almost ready except we need to backport lots of things from 193 because they forgot to include it in the release and 193 is already in experimental so if you want to experiment with it it's easy, what's missing there is a way to solve the facts that in the Ruby interpreter world, they have something called Ruby compatibility version which is about the same as the version sort of and so you can't go install 192 and 193 and currently in Debian the package are numbered with the Ruby compatibility version which means that the package are versioned 191 not 192 so it's a bit confusing because we install Ruby 191 and you get Ruby 192 ah the problem is well I tried to to push upstream so that they would change the compatibility version at each major new release so that the 193 would be compatibility version 193 but they said it was our problem to fix and well so what we still need to do is add some some sugar on top of the existing packages so that you can install Ruby 193 and get Ruby 193 which probably means just introducing another package that depends on Ruby 191 but just to make people happy about that they still need to be done there's also work on Ruby policy document everything that changed with Gem2Deb, Vincent Fourmont is leading this but there's also work on packaging other interpreters so that's mainly JRuby which is currently non free because it uses a ton of jars that needs to be packaged in Debian and Ruby News which uses LLVM which has been ITPed but it's currently what people call cookie leaking mode cookie leaking mode is one is in a community is doing something but not really doing it and each time someone says oh I'd like to help that person says oh no need to help me I have something almost ready I will upload in 2 days and it has been like that just leak the cookie so that someone else cannot have it and it has been happening playing like that since 6 months but since nobody is sufficiently motivated to take it over it stays like that so we have some time remaining for question and discussions so some things I'd like to discuss is the default version for Weezy so the current status upstream for 1.8 is that it will be into normal maintenance probably we will have another 1.8 release 1.8.7 release before June 2012 and we'll get security support until June 2013 but it would probably make sense to at least consider switching to 1.9 and the best candidate is 1.9.3 because 1.9.2 won't be maintained more than a few months from now so well that's open for discussion something else is well June today if you have tried it and have questions, commands rants about it don't hesitate if you are maintaining Ruby packages but outside the team I would be interested to hear what you are doing that and what's missing in the team to make you switch to the team because you would really appreciate to have you in the team and helping Gunnar can probably say something about two applications packaging to tell you clueless about two applications and then well if you want to work on these things together just say it Given that Luca specifically called on me on previous dev confs we have had a similar talk both to this one and well I propose it at one point mainly targeted at trying to get rails things going easier in the bien Ruby has many what frameworks one of them is rails, maybe the most popular but for many reasons both internal and external to the rails community more getting attention such as camping and well rails is migrating to become a stack of web oriented things which I think is good now currently the status those packages is not as good as it should also because of incompatibilities with the mindset and the world view that they have I mean this thing that they insist on us running everybody the latest release of everything it makes it hard to work with devian so right now we are still packaging only the 23.8 I think or 23.5 version of rails while the 3.0 has been stable for quite a long time but I think nobody within the team is motivated to package the new one which includes very very large changes now we have managed to have at least one rails application packaged in devian, it's red mine now the amount of bugs that red mine has triggered is tremendous because it's so hard to get right so well at least for my work I am packaging some libraries, I am not currently tracking or trying to work with any complete systems but I know some people are precisely interested in that well for red mine one thing can be said that there was a huge number of bugs which also indicates a huge number of people interested in using it on devian so it looks like people are not well, I'm not really happy with jam install way of installing applications such as red mine other questions what do you think about 1.93 by default for example ok so far now I bring this up especially I like to see 1.9 as the new default so our internal applications all switch to 1.9 already and we haven't seen we have seen some breakage but not a lot most jams appear to have been converted already or just work as is just some very very old jams break so that should be nice another thing I'd like to bring up is what are you doing for the for libraries that are packaged that are merged in standard which are also available besides of standard especially now that jams is in standard and rake is in standard and there are significant updates yeah so I don't remember but we have a plan for it and since I don't have internet it would be hard to look up the wiki page about it can you maybe remember what we do about lips that are merged in the standard library or lips that are removed from the standard library because this also happens I haven't really worked with that part no well if you're looking into it I just wanted to ask what you say it really makes sense to migrate to 1.9 as a default there are many things that are basically broken in 1.8 starting with the utf support I've found so many bugs that could be averted if we change the default and with the way one of the things that are most nicely solved with jump to death is that the fact well you mentioned it but I have to restress it currently well with the previous infrastructure we were building one binary package per interpreter and having 1.8 as a default meant that many of my packages if they didn't build cleanly at the first pass with 1.9 I thought oh fuck it discarded 1.9 and built only 1.8 so we have many packages which are currently not available for 1.9 and that creates a vicious circle because the developers don't migrate up the users don't migrate up and well the language feels the same but in rubies community where they don't really value stability in some things many behaviors start diverging so we have some bugs that are triggered by specific version combinations and I think we can deploy them perfectly by making a switch well I was looking for the plan for well I can look it up on the list archive who are you sorry so I can forward it to you who are you who am I I'm Christian ok well send me an email about our plan you can tell if it's ok other questions ok well thank you