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