Paul van Tilburg <paul / luon.net> writes:

> 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.

True, but it does no harm if you can easily change it.
There may be lots of reasons not to use a directory layout like that.

>> * 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.

I've been talking to #debian-ruby yesterday already.  Cooperation with
packagers is important for success.  Packagers of other distributions
and projects are welcome to mail me.

>> 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.

I was just thinking, it *defines* what is in an Package, doesn't it?

>> 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!

Thank you, I'll come back on you.

>> 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.

Being not a Ruby core developer, I don't have influence into that.
However, I think rbconfig can (and should) be cleaned up a lot.
Maybe you do want to bring up this issue on ruby-core?

For a start, rbconfig is useful enough for getting standard paths,
though.  Package will provide support to make use of alternative
paths, just like distutils do it.

> Good stuff, great!
> Regards,

Thanks a lot!

> Paul
-- 
Christian Neukirchen  <chneukirchen / gmail.com>  http://chneukirchen.org