[This is a double-post due to an identity mistake, my apology
to the moderators.]

Hi!

Am 27.01.2015 um 02:10 schrieb Noel Torres:
> On Sunday, 25 de January de 2015 00:04:32 tilt escribió:
> [...]
>> Question: How will volunteer version the new package?
>
> Hi tilt
>
> I think adding +devuan at the end of the package version was
> discussed, as well as changing the package name to avoid that
> a bump in Debian's version crushes our package.
>
> I'm not sure if something was agreed, I think it was not.

Thanks a lot for the feedback!

Right now I practise "+devuanX" re-versioning, so if I
encounter a hypothetical incoming package with name "xyz"
and version (in Jessie) "1.2.3-4" then my modified package
will still be called "xyz" and the version will be
"1.2.3-4+devuan1" (and if have to revise it, "+devuan2"
and so on).

I do understand the "Bumping" problem you mentioned, but
package renaming has problems, too:

Let's assume hypothetical incoming package "xyz". I make a
modified version and rename it to, for example, "xyz-devuan".
Binary packages will be "libxyz0-devuan", "xyz-devuan-doc" and
so on. I add "Provides" relations and set them to "libxyz0",
"xyz-doc" and so on. Providing virtual packages of the same
name as concrete packages is valid according to [DEBPOL7.5]
paragraph 3.

But according to [DEBPOL7.5] paragraph 4, as soon as another
package Depends on a specific package version, virtual
packages will not be considered for satisfying relations
anymore, thus excluding our package "xyz-devuan", at least
from any form of automatic dependency resolution. Therefore,

I feel package renaming introduces lots of work for a limited
reward.

Kind regards,
tilt.

Reference: [DEBPOL7.5]
Debian Policy Manual.Section 7.5: "Virtual packages - Provides"
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual