Bug#975381: Subject: libinih: drop Debian's custom vendorisation
On 2020-11-21 Stephan Lachnit wrote: [...] > 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. Hello, goxel does.[1] goxel-0.10.6/src/utils/ini.h:#define INI_HANDLER_LINENO 1 and gnutls would, too. So imho inih upstream needs a interface that allows linking either dynamically against system libinih or statically against the included copy without changing the source with something equivalent to the compile time options. The current Debian-patched version requires source changes depending on what linkage is targeted, upstream's version of the dynamic library just does not work when these compile time options are needed. cu Andreas [1] Which is probably why it actually uses the static copy although it depends on libinih. (#978021) -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
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. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#975381: Subject: libinih: drop Debian's custom vendorisation
-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-
Bug#975381: Subject: libinih: drop Debian's custom vendorisation
Stephan Lachnit 于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.
