[DRE-maint] ruby-setup-rb.mk, and ftbses

[Antonio Terceiro]

Gunnar Wolf escreveu isso aí:
> Lucas Nussbaum dijo [Sat, Jan 12, 2008 at 08:14:54PM +0100]:
> > > This is the point, the class links setup.rb if one is not already
> > > present in upstream source. So at clean time, it removes it only if it
> > > is a symlink. (This code extract is in the clean target.)
> > > BTW the fix is not mine.
> > 
> > This doesn't work. The idea is to always use setup.rb from the package.
> > Using upstream's setup.rb will make us use old versions of setup.rb,
> > which won't support some of the options we use.
> 
> AIUI, this might end up not working - Setup.rb does _not_ claim to
> maintain backwards compatibility. From the documentation [1]:
> 
>    Backward Compatibility
> 
>     I do not assure any backward compatibility for the setup.rb. If
>     you'd like old behavior, just use old version.
> 
> I think that, if upstream ships a setup.rb, we should just use
> it. libsetup-ruby should be useful in the (many) cases where we
> _don't_ have it.
> 
> [1] http://i.loveruby.net/en/man/setup/devel.html

The problem is that some older versions have different command line interfaces
accepting different sets of options. --installdirs, for instance, is not
accepted by older versions.

We have two options:

1) use packaged setup.rb only when upstream does not ship one

Advantages:

  * build process should be very similar, if not equal, to upstream's;
  * build can behave differently among different packages due to
    different setup.rb versions.

Disadvantages: 

  * ruby-pkg-tools must cope with different setup.rb versions, and pass
    different command line arguments to each one.

2) always use packaged setup.rb even if upstream provides one.

Advantages:

  * ruby-pkg-tools is kept simpler
  * all packages should build the same way in Debian, at least on the
    setup.rb part of the build.

Disadvantages:

  * build process may be different from upstream's; maintainer must
    check that the Debian build works as expected.

It would be nice if others can expand this advantages/disadvantages, and
even add more choices so we can reach a consensual decision is possible.

-- 
Antonio Terceiro <terceiro at softwarelivre.org>
http://people.softwarelivre.org/~terceiro/
GnuPG ID: 0F9CB28F