[tryton-debian] Future of the Tryton suite in Debian

[Mathias Behrle]

* Nicolas Évrard: " Re: [tryton-debian] Future of the Tryton suite in
  Debian" (Sun, 29 Apr 2018 01:01:50 +0200):

> * Mathias Behrle  [2018-04-28 00:10 +0200]: 

[...]

> I assumed that modules defined in the extras_depend would be good
> suggests modules.
> 
> But now I've taken a look at tryton-modules-project-revenue which in
> upstream has an extras_depend on the purchase module. Yet it does not
> appear in the Suggests.
> 
> According to the policy:
> 
>     Suggests is used to declare that one package may be more useful
>     with one or more others.
> 
> I thought that modules in extras_depend qualified for this.
> 
> Could you explain the reasoning behind not using this field?

extras_depend in Tryton are generally used to make work another module with the
module in question. This is different from Suggests.

In this very special case:
Why should someone who wants to manage the revenue of projects be automatically
interested in purchases? If we would want to define such a loose
relationship, all Tryton modules (tryton-modules-all) could more or less be
listed in the Suggests of each module, because all modules could have a
distant use case where you could want use another module. extras_depend is not a
good indicator for Suggests.

[...]

> Of course. I assume you won't package 4.8, will you?

The current state is that I received thankfully the commitment for the packaging
of 5.0, which will be just in time for Buster and in any case the right release
(LTS) to go with in Debian. I will put a note in this regard ASAP on the
lists.

There is no sponsoring (yet) for 4.8, right.

> I suppose I can make merge requests on for this new release anyway,
> no? (I don't know when it will happen as I guess I still have some
> stuffs to learn).

Merge requests for what and where? I don't understand the question.
 
[...]

> >PS:
> >If it is intended to include the module in the backports and expected that
> >I should do the maintenance with the rest of the suite it is essential to
> >provide a git repos (preferably on salsa.debian.org, it should be easy to
> >get an account) which matches exactly the branching layout of the existing
> >modules.  
> 
> Of course I prefer if this package is included in the backports as it
> will benefit everybody. But as you said, this package is far from
> being ready and moreover I just learned about the existence of the
> infrastructure on salsa.d.o and the existence of gbp a few days ago
> (but I can understand why you prefer it that way then the cumbersome
> manual tasks I had to perform to create the package).

I don't understand the last sentence. The hosting of the package source in a
git repository with a suitable layout to document and ease its maintenance has
nothing to do with just copying over and adapting a module torso. What did you
want to say?
 
> So of course I will follow the branching layout of the existing
> modules.

Thanks,


-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
    AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6