On Mon, Oct 05, 2020 at 01:23:22AM +0200, Daniel Leidert wrote:
> Am Samstag, den 03.10.2020, 23:23 +0200 schrieb Cédric Boutillier:
> > Dear Team members,
> >
> > I had a couple of questions about packaging workflow, which are maybe
> > naive. Hopefully, answers will be useful for others too!
> > I am sending them as separate emails.
> >
> >
> > 1. exact role of ${ruby:Depends}
> >
> > I kind of understand from the dh_ruby manpage that ${ruby:Depends} is
> > supposed to fill in the Depends: field for the binary package, using
> > information from the gemspec. It is nice.
>
> I actually would like to see this handle ruby-foo packages using epochs too
> like ruby-activesupport (or does it handle this already and I missed it?).
It doesn't, at the moment. I think it could work if we hardcode a list of
packages that have epochs in gem2deb itself (which is ugly, but I don't
see any other way).
> It would also be nice if it could handle packages as weel with don't use the
> ruby-foo naming scheme like jekyll.
This is already handled just fine, as long as `foo` provides rubygems
metadata correctly. `ruby-foo` is only used as a fallback if there is no
metadata to do the mapping.
> > I was wondering if we, as a team, would consider as a guideline to try
> > to replace the hardcoded dependency by ${ruby:Depends} (as dh_make_ruby
> > -w does) when updating a package.
>
> I actually did that in every package I touched if the dependencies allowed it
> (see above).
Me too.
And in general I think the debian/ directory generated by dh-make-ruby
should always encode all the best practicees, and be the target when
updating packages.
signature.asc
Description: PGP signature
