[DRE-maint] Minutes meeting 2007/09/17

Paul van Tilburg paulvt at debian.org
Sat Oct 6 13:05:40 UTC 2007


Hello everyone,

I hope that everyone had a good summer (or winter) holiday.  It has been
relatively quiet for a while.  I am also party to blame for that.
I have been finishing my studies and settling in my new job.  Somehow
this resulted in me not getting around to writing the minutes of the
meeting we held at Debconf.  Now, I want to get back to some action
here, and started with writing the minutes since they contain quite
a few action point we can tackle.  

I feel a bit ashamed that it has taken almost 11 weeks and I must admit
that my notes where that extensive, so bits got lost but I'm confident
we can recover from this :).  I'll include the minutes verbatim for
replying purposes, but I have them in a separate file which I will
probably check into the repository.  If you want to start a discussion
about more than one item, please create separate replies for
nice-threading purpose.



Minutes Meeting Debian/Ruby Extras Team
=======================================

Date, Time: 2007/07/19, 18:00
Location: Teviot Row House, Edinburgh (DebConf 7)

Agenda:
1. Introduction
2. Policy discussion
3. Team issues
4. Misc items
5. Conclusion

---------------------------------------


1. Introduction
---------------

Quite a few members of the team joined the meeting, but we also had the
pleasure of other people being present how might want to join the team
and/or help out.  Present were:
Lucas, Gravity, Ralph, Gwolf, Ralph, Kibi, Mozillion, and two others
whose names are lost to me (sorry!).


2. Policy
---------

** Move libraries from /usr/lib to /usr/share:

The FHS is actually not very clear about this.  On one hand, the pure
Ruby libraries are architecture independent files and therefore should
be in /usr/share.  On the other hand, we are talking on libraries used
by programs here, so maybe they should be in /usr/lib.  Perl has the
/usr/lib <> /usr/share separation, but Python does not.  It was
suggested that this is hard to change in Ruby upstream, but this is in
fact not the case, because the Debian/Ruby interpreter guys could change
this configure-time.

-> Discuss library path standards with the Debian/Ruby interpreter team.

** Documentation (RDoc paths, RI paths/fixes, dh_rdoc):

Quite a while already, dh_rdoc has been available (and used) by our Ruby
package tools.  However, at the moment, this is only called/used
automatically when a -doc package is mention in debian/control.  This
-doc package however should only be used when the documentation is rather
large.  Hence, most package do not carry documentation or install this
in an arbitrary way.  Also, dh_rdoc should be updated to either install
HTML documentation that is part of upstream at a consistent place, or
generate it and install it for _all_ libraries.  Someone suggests that
we also should register this documentation with doc-base, everyone
agrees.

-> Update dh_rdoc to also handle upstream documentation installing.
-> Update _all_ library packages to either install or generate RDoc HTML
   documentation and register it with doc-base.

There are also issues with installing RI documentation.  This
documentation is as useful to people (or more) as the HTML documetation
is.  However, there is no standard for installing RI documentation
location-wise (e.g. to avoid class conflicts).

-> Discuss RI-docs install standard with the Debian/Ruby interpreter team.

** Versioning:

The central question is:  can we get rid of -rubyX.Y versioned packages
and all these dummy packages?  While packaging lots of libs we found out
that this is an enormous hassle.  Debian/Python has been able to get rid
of them, Debian/Perl never really had them.  At the moment, arbitrary
source packages produce a -ruby1.9 binary package.  Some non-team
controlled package only have a -ruby binary package and not -ruby1.8
package whatsoever.  Do we need to deal with a possible future
transition this way, or can we do this more cleanly?

Another issue that was raised is that for example, at the moment, a lot
of packages depend on ruby1.8 while they actually mean that they require
stdlib, which is libruby1.8.  Should all packages be adapted?

-> Discuss more about versioning and ruby/libruby dependancies
   on the team list.

** Shebang in library files:

Lintian generates lots of errors for packages which contain library
files (/usr/lib/ruby/..../....rb) which contain a shebang.  This stems
from in upstream executable files which could be run from the
command line to perform inline included unit tests.  The complaint is
that a file with a shebang is installed non-executable.  Making it
executable is not an option and removing the shebang using patches for
every .rb file is a hassle.   

-> Ask the lintian people what is the proper thing to do.


3. Team Issues
--------------

** Maintainer/Uploaders field:

Lucas proposed a while ago to change the meaning of the Maintainer and
Uploaders field.  Most package have been adapted by now, following the
following convention:  
the main responsible team member is listed as the Maintainer, while the
team list/address is put in the Uploaders field as well as people who
are interested in working on the package or are sponsoring it.  (This
works fine considering the nature of team/our team structure).
However, the disadvantage of having the team list/address in the
Uploaders field instead of the Maintainer field, we lose team-wide
notifications if there are bugreports or other issues.  Lucas proposes
to subscribe the team list to all our packages in the PTS.

-> Subscribe the team list in the PTS to all packages supported by the team.


4. Misc Items
-------------

** Multiple version of setup.rb/install.rb

Almost all upstream comes with different versions of install.rb/
setup.rb.  This results in having to pass all kinds of override
parameters to the default ruby-setup-rb CDBS class.  We might consider
packaging libsetup-ruby all together and let our classes use that, since
the directory structure that setup.rb uses hasn't changed over the
years, it has only been extended.

-> Package libsetup-ruby.

** Rake/rant

Some of the people present at the meeting work with rake, or better (in
their opinion), rant.  They offered to assist us to create a framework
for building packages.

-> Investigating rant integration in our tools.

** RubyGems

The question is raised whether we have to change our position towards
RubyGems.  A long discussions follows which describes our disagreements
with the Ruby(Gem) community.  The conclusion is that we can keep our
position statement as is.  More discussion can follow on the list
later.


5. Conclusion
-------------

The meeting was productive and it is clear that more meetings would be
certainly worth considering.  Action points:

 * Discuss library path standards with the Debian/Ruby interpreter team.
 * Update dh_rdoc to also handle upstream documentation installing.
 * Update _all_ library packages to either install or generate RDoc HTML
   documentation and register it with doc-base. 
 * Discuss RI docs install standard with the Debian/Ruby interpreter team.
 * Discuss more about versioning and ruby/libruby dependancies
   on the team list.
 * Ask the lintian people what is the proper thing to do.
 * Subscribe the team list in the PTS to all packages supported by the team.
 * Package libsetup-ruby.
 * Investigating rant integration in our tools.


Kind regards,
Paul

-- 
PhD Student @ Eindhoven                     | email: paulvt at debian.org
University of Technology, The Netherlands   | JID: paul at luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20071006/78db482c/attachment.pgp 


More information about the Pkg-ruby-extras-maintainers mailing list