[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#975381: Subject: libinih: drop Debian's custom vendorisation

control: tag -1 + moreinfo

Dear Stephan,

On Sat 21 Nov 2020 at 12:20PM GMT, Stephan Lachnit wrote:

> Currently the package libinih uses some heavy patches, which aren't upstream
> and aren't used by any other distro. I'm in favor of dropping this, but the
> current maintainer disagrees and we weren't able to make any progess in the
> discussion, so I want to put this here. Parts of the discussion can be found on
> this MR: https://salsa.debian.org/yangfl-guest/inih/-/merge_requests/2
> To understand this, one has to look a bit at the history behind inih. Upstream
> was designed as a static library for embedded devices, and therefore has a lot
> of compile time options. At this point, the current maintainer created a patch
> to make all compile time option available on runtime.
> When gamemode started using inih, I wanted to get rid of shipped inih code and
> upstreamed a build system to inih for a shared library, that any distro can
> use. This was done in version 48. Due to the popularity of gamemode, inih is
> now found in most major distros (all without Debian's patches):
> https://repology.org/project/inih/versions
> There is a notable "exception": inih is not in Ubuntu's main repository. This
> is a bit weird because gamemode is in main, but with the shipped inih source
> which got dropped from 1.6, meaning gamemode is stuck on 1.5.1 on Ubuntu. I'm
> not sure why, but I suspect the heavy patches make it harder to be included in
> main.
> Because the library was designed for embedded use cases where every little bit
> of performance matters, the runtime patch was refused upstream. Dropping the
> runtime patch from Debian actually isn't problem, no reverse dependency of
> libinih uses compile time options anyway. However, due to the history of inih
> in Debian is has the soversion 1, while upstream is soversion 0.
> I want to drop the vendorisation of Debian and start a transition to soversion
> 0 (which is also a reason I contact the Technical Committee, as it's not clear
> how this would be done). A transition is needed anyway since dropping the patch
> is a breaking change anyway. If the Technical Committee agrees to this, I would
> also gladly help to maintain this package since it is 2 version behind upstream
> since almost half a year and I maintain gamemode, which is directly affected by
> this.

Your message it not clear enough for TC members not familiar with the
packages in question to understand what the dispute is.  We cannot wade
through discussions on salsa -- we need a summary.

Please make another attempt at summarising the dispute.  Please also
indicate which of the TC's powers (as granted by the constitution) you
are asking us to make use of.


Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply to: