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

Lucas Nussbaum lucas at lucas-nussbaum.net
Thu Jan 17 05:50:10 UTC 2008


On 14/01/08 at 16:27 -0300, Antonio Terceiro wrote:
> 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.

I would say that the maintainer is expected to check that his package
works fine already ;)

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

I'm wondering if there are people who oppose going with (2) inside the
team? If so, what is your reasoning? (you can point me to past mails on
the topic, I might have missed them)

I think that we have to think of that issue in terms of toolchain.
setup.rb is like a compiler. It makes a lot more sense to compile all
our packages with the same version of the compiler, and adapt the
packages if needed, than to use a different compiler for each package,
and ship the compiler inside the package.

Also, if an upstream adds features to setup.rb, we could always make it
a special case, and use the setup.rb shipped by upstream, but only for
this package.
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |



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