On Sun, Jun 05, 2005 at 07:59:15AM +0900, Christian Neukirchen wrote: > What advantages will Package have over setup.rb and mkmf.rb, as > they are now? > > * simple, clean and consistent working > * unified library to handle both extensions and libraries > * lightweight approach (if included in the standard library) > * easy adaption Very nice. > * more flexible directory layout: especially small projects > profit from this, as setup.rb's directory layout is quite > bulky by default and not very customizable I am still not sure that this is a disadvantage. Probably you are referring to the lib/<foo-lib>/ thing, to have to create that subdirectory everytime. While this may seem bulky, it is easy for the mind. You just know that lib/* is copied to whatever ruby libdir is configured. The same holds for data/, conf/, etc. > * easier packaging by third-party packagers due to simple > but flexible and standardized invocation This is a big advantage. I've seen RPA make a small step in the same direction, being able to create the debian/ subdirectory for RPA's metadata file. While the result almost always has to be tweaked, it's a big help as starting point. I think that I can speak for the Debian Ruby Maintainers Team that we will back this effort. > What do we need to get a wide adoption of Package? > > * inclusion in the standard library so it doesn't need to be > shipped with every package (as setup.rb unfortunately is). > * backing from the community to make use of Package. > * acceptance from packaging projects like RPA, RubyGems and > distributions like Debian, FreeBSD and PLD. Yeah, maybe the name is misleading. It does nothing for packaging, it stays completely out of the packaging scope (although it's a bit relevant :)). Something like distutils is also not really covering it, it does not aid in distribution, it is a system for configuring/building/installing. Maybe Setup/Installer is a better them, it is associated with the act of copying the files. > Coding of Package has not started yet (the name is also not set into > stone yet, so if you have better ideas, please tell me) because it > would be pointless without a strong feedback from the community. I > expect to get a first version done rather quickly, possibly borrowing > code from setup.rb and mkmf.rb, but Package will not depend on these > both. If anyone is interested in helping development, please mail me; > helpful hands are always of use. Also, there will be need for testers > on all and even the most weird platforms. I'll help you in both areas if and when I can! > But now, I'll ask you: Are you satisfied with the way installing Ruby > extensions and libraries works? Yes. I usually use setup.rb for this, for it's simplicitly. I have never done C bindings and stuff, so it always has been pure Ruby for me. There are many methods to install stuff these days, supplied Rakefiles, Rantfiles, setup.rb, extconf.rb, mkmf.rb etc. I never understood why some part hasn't been abstracted from and put in a library yet. > Do you think there is a place for Package? I strongly do. > Do you have further improvements or can provide alternative ideas? Well, I reckon that some things have to be thought out yet, there are many good things in setup.rb, mkmf.rb etc. and those things can be combined IMO. We'll see how it goes. Just one thing. I think it's a good thing if Package should use the paths specified by Ruby's rbconfig, but that one has to be cleaned up. I hate to say it, but (at least from the perpective of a 3rd party Ruby distributor) it has become a mess. So something has to be changed in that area as well. Good stuff, great! Regards, Paul -- Student @ Eindhoven | email: paulvt / debian.org University of Technology, The Netherlands | JID: paul / luon.net >>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181