Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Thu, Jun 04, 2020 at 12:25:39PM +0200, Roland Plüss wrote:
>
> On 6/2/20 1:05 PM, Tobias Frost wrote:
> > On Mon, Jun 01, 2020 at 04:13:33PM +0200, Roland Plüss wrote:
> >> On 5/31/20 9:19 AM, Tobias Frost wrote:
> > (...)
> >
> >>> It seems at first glance possible that both versions can be in Debian,
> >>> however, the release/security team will not be happy to have both of
> >>> them in a stable release, IOW, having two versions can only be a
> >>> intermediate solution until all reverse dependencies of 1.6* have been
> >>> updated (by patching the respective Debian packages.) More about such
> >>> library transision:
> >>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> >>>
> >> FOX-1.7 and FOX-1.6 are not compatible (well, mostly yes but in
> >> important things not). That said they are different libraries with
> >> separate include and library names (/usr/include/fox-1.6 vs
> >> /usr/include/fox-1.7 and the same for libraries). So technically
> >> applications linking against FOX-1.6 do not have to be change if FOX-1.7
> >> is added on the same system (the two can coexist). But it depends if two
> >> library versions of the same library are accepted even if they are disjoint.
> > Those versions are not disjoint, the new version is just an evolution of the
> > old one.
> >
> >
> > Incompatible ABI changes is nothing special and happens all the time in Debian
> > (called library transistios). As I tried to explain earlier, the maintainer
> > duty is to resolve this by a transistion when updating the library.
> >
> > For you, hat means you need either 1.6 for code base or you need to help that
> > all of Debian is using 1.7. You can't have both versions in Debian…
> >
> I don't see any way for me to get other projects to update to 1.7 . FOX
> separates 1.7 from 1.6 so projects are not forced to upgrade if they
> don't want to.
This would not be the first library transition that requires patches to
packages in the archives. If upstreams accept those patches is a different
story, orthogonal to this discussion.
However, I want to make sure you understand, when your package is accepted, and
a library transition is impacting your package, the same rules will apply to
you: You will need to work with the library's maintainer to make your package
compatible with the new version. It will be not an option to stay at the old
version of the library. That would be not how distributions work.
> I can try ask the maintainer but I consider this a 0% success rate.
I don't agree. Though 1.7 is a development version and it depends on the
maintainer if they accept it, you will not know until you have filed that bug.
So please assume good faith first, it could be that the maintainer acutally
likes the idea.
--
tobi
Reply to: