Bug#975381: Subject: libinih: drop Debian's custom vendorisation
Stephan Lachnit <stephanlachnit@protonmail.com> 于2020年11月21日周六 下午8:20写道：
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Package: tech-ctte
> Severity: wishlist
>
> 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.
>
> This isn't urgent, but it would be nice to get this done till bulleseye.
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEu0Wws/9WG9vUXuips1tJ6l1WPv4FAl+5BWIACgkQs1tJ6l1W
> Pv7dyA//QMHV+BGlUzXIMCcBlkVnYe85/TT8xH2peZTZ7j5ULBwvGGVhYG1Dt8/A
> PcziDIcVLhmEN6N5r9vTispp0McTy5nNpotVgZ/5KJ1+WzRS+7D1YGXyS6YOTF7H
> p4rK7PMMok8Yvjrxe/k8TRqRL6tw9+1cXRYhSBQg0TQGPTCEPh5nlWSgSOTKyHAe
> ZAcpeUmLXvI0fLHiKAyxtI2nVPadWy+MFlJP4oJU1ml5+4ZUqDZ/DcC+qeHE8tSh
> 8oFdtG4/3REtb1e2x0LfeV45oj/MBv7X6IyWaw5vvjzLEiZHxuY8SRgMpgBzkNaC
> y675orpcwNKFFkA5PdlxtGstDfzoUi70Gl8sNMNFt26w3+eX9+w/CxpgSIftHp6/
> 2cJRlgjfN6a2Eog9skq6XhGGoVZ1HHjq1mAtinKw9Wv0L88hd62PCzRu+ZVScGr8
> MNK43VxbP2PCBMWY5z9uFlANBbgY4R4wPbKjZmH9NJW3yJDXHeKjCGfDrw3KX/5l
> eIC+CbfEMuPHl02HY6TJwn0cDeEsRiyrLA+4aHrG1Vxy92L+4PPsQuJts6DzmGej
> HNiyXvaSC88ovkOk2mgxtPx+dgI3qpmpMzJYqkpHg2Eo5zn12DpiubsZRHmR/1Fz
> hrE4lwvV3W1DN4ztQs/Faa9zsRgPrhgEVKJMuqCwLSDeMovXCsY=
> =kj7T
> -----END PGP SIGNATURE-----
I think I've stated it clearly: you have not placed any valid
objection against the patch. Performance is not an issue on Debian,
and as a Debian maintainer, I have zero responsibility for any Ubuntu
stuff. IIRC, a package is not in Ubuntu main repo simply because no
one in Ubuntu side maintain it.
If you can't come up with an objection, I can give you one now: the
option affect globally, meaning that if a library modifies one option,
other part of that program will be affected. But my opinion is, as
long as the library is only linked against the main program, nothing
bad will happen. See #958243, in that case, they DO use modified inih.
The reason I have not catched up with the upstream release is they tag
every single git commit as a release, and no breaking changes happened
in that 2 releases (except for a new compile option). However if I'm
wrong or you'd like a new release, you could file a new bug for
updating.
Reply to: