Re: Question about library package splitting
Hi Guillem, first of all, many thanks for your answer! And sorry for my late reply... On Sat, Sep 07, 2024 at 02:46:13AM +0200, Guillem Jover wrote: > On Fri, 2024-09-06 at 11:32:55 +0200, Ervin Hegedüs wrote: > > I think ideally upstream would be modified so that this decision can > be made somehow at runtime? Then most of the problem presented goes > away. yes, that's a possible solution - I'm going to check that option. > > I don't want to force users to use LMDB, rather I prefer to deliver two > > library packages: one with in-memory and one with LMDB. > > See above about making this a run-time selection. But if this is not > feasible or upstream does not want to go that way, the problem I see > is that selecting how the library behaves then becomes a system global > binary selection of behavior, depending on what implementation is > installed. yes, exactly. > > I couldn't find any guideline in Debian packaging documentation but found > > the libcurl-dev as a pattern. > > I think this is somewhat different, as these are co-installable, and > whether to use one or the other is selected by the package using it > at build time, not by the user. yes, but the two package will install a shared object with same name. Or I don't see the point here. > Even with the above, if you still want to go in this direction: > > > * in this case the API hides the differences between two solutions; Is it > > enough to make one -dev package and two different runtime packages? > > Given that this seems to be an implementation detail and supposedly > neither the API nor ABI change, and this seems to be intended as a > mechanism for the *user* to select the implementation, and not the > package linking against it to select it, then I think a single -dev > package would be better. right, > In this case how to allow switching implementations can be done either > via Provides+Conflicts+Replaces; or Conflicts+Replaces and then making > the symbols or shlibs file generate dependencies on both library as > alternatives such as «libfoo | libfoo-lmdb». right, thanks, > > * are the names acceptable "libmodsecurity3t64" and > > "libmodsecurity3-lmdbt64"? > > The t64 suffix for the lmdb one should not be needed. okay, > > * based on the test package, are there any comments or advice to be > > considered? > > Some passing and non-exhaustive packaging comments: > > - autotools should support out-of-tree builds, so there should be no > need to copy the source tree into a subdirectory, just creating the > subdir and calling ../configure should do. > - you can use execute_after_ or execute_before_, instead of duplicating > the dh calls. > - you do not need the .dirs fragment files, as the .install ones > should take care of creating the needed directories. > - debian/compat is deprecated, you can use debhelper-compat (= 13) > instead. > - if you are going to support omitting specific packages per > build-profile, then you should add a Build-Profile field to the > relevant binary packages, so that they do not get built at all, > and then also annotate the lmdb build dependency, although this all > seems a bit excessive? thanks for these too. I'm going to investigate how can we change/add a feature to select the backend after installation, and if it's too complicated, then I try to split the package. Many thanks again! a.
Bug#1082940: ITP: python-simplepush -- simplepush Python library
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-simplepush Version : 2.2.3 Upstream Contact: Timm Schaeuble * URL : https://github.com/simplepush/simplepush-python * License : Expat Programming Lang: Python Description : simplepush Python library Python module to send push notifications via simplepush. This library allows sending notifications synchronously and asynchronously. This is a dependency for homeassistant. It will be maintained under the Home Assistant Team.
Re: proposal to drop licence compatibility checks from adequate
[adding -devel, for wider visiblity] On Sun Sep 8, 2024 at 6:31 PM CEST, Serafeim (Serafi) Zanikolas wrote: > hi, > > I've recently taken over adequate(1) and am considering to drop its license > compatibility checks, for several reasons: > > - unlike 2013, which is when adequate grew this functionality, today many > well-funded organizations actively care about license compliance (e.g. see > fossology.org), so I'd expect major cases of non-compliance to be noticed > - afaict in almost 11 years of adequate's existence, only one actual case of > non-compliance was found (#749801) [0] > - the relevant logic is non-trivial, and prone to false positives in the case > of binary packages shipping multiple libraries with different licenses; it > also hardwires soname/license/version mappings for major libraries (I'd > guess > as a workaround for the aforementioned issue), which I consider > unsustainable > from a maintenance PoV > > if you feel strongly against this proposal, you're more than welcome to join > the > adequate maintainers team (today, just me) and make your case with code. of > course you're also welcome to join even if you do agree with the proposal! > > thanks, > serafi > > ps. please cc me in replies > > [0] I've looked at piuparts and adequate tagged bugs signature.asc Description: PGP signature
Bug#1082943: ITP: libmsoffice-word-template-perl -- Perl module for creating Microsoft Word documents from Word templates
Package: wnpp Owner: Damyan Ivanov Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libmsoffice-word-template-perl Version : 2.04 Upstream Author : Laurent Dami * URL : https://metacpan.org/release/MsOffice-Word-Template * License : Artistic-2.0 Programming Lang: Perl Description : Perl module for creating Microsoft Word documents from Word templates MsOffice::Word::Template module treats a Microsoft Word document as a template for generating other documents. The idea is similar to the "mail merge" functionality in Word, but with much richer possibilities. The whole power of a Perl templating engine can be exploited, for example for * dealing with complex, nested datastructures * using control directives for loops, conditionals, subroutines, etc. * defining custom data processing functions or macros Template authors just use basic highlighing in MsWord to mark the templating directives. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1082942: ITP: libcarp-object-perl -- object-oriented replacement for Carp or Carp::Clan Perl modules
Package: wnpp Owner: Damyan Ivanov Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libcarp-object-perl Version : 1.02 Upstream Author : Laurent Dami * URL : https://metacpan.org/release/Carp-Object * License : Artistic or GPL-1+ Programming Lang: Perl Description : object-oriented replacement for Carp or Carp::Clan Perl modules Carp::Object is an object-oriented alternative to Carp/croak or Carp::Clan/croak, for reporting errors in modules from the perspective of the caller instead of reporting the internal implementation line where the error occurs. Carp or Carp::Clan were designed long ago, at a time when Perl had no support yet for object-oriented programming; therefore they only have a functional API that is not very well suited for extensions. The present module attemps to mimic the same behaviour, but with an object-oriented implementation that offers more tuning options, and also supports errors raised as Exception objects. Unlike Carp or Carp::Clan, where the presentation of stack frames is hard-coded, here it is delegated to Devel::StackTrace. This means that clients can also take advantage of options in Devel::StackTrace to tune the output -- or even replace it by another class. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1082945: ITP: libmsoffice-word-surgeon-perl -- Perl module for modifying docx documents using regular expressions
Package: wnpp Owner: Damyan Ivanov Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libmsoffice-word-surgeon-perl Version : 2.08 Upstream Author : Laurent Dami * URL : https://metacpan.org/release/MsOffice-Word-Surgeon * License : Artistic-2.0 Programming Lang: Perl Description : Perl module for modifying docx documents using regular expressions MsOffice::Word::Surgeon supports a few operations for modifying or extracting text from Microsoft Word documents in '.docx' format -- therefore the name 'surgeon'. There is no functionality for creating Word documents from scratch. The package is a dependency of libmsoffice-word-template-perl (ITP #1082943) and will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: Default Arabic Font change proposal
Hi Mohamed,
On Mon, Sep 02, 2024 at 12:41:54PM +0200, Mohamed Aboelenein wrote:
>Hello,
>I am not exactly sure if this is the right way to do it. If not, I hope
>you notify me.
This isn't the right forum, indeed. The debian-vote mailinglist is meant
for votes by Debian Developers as procedurally required from time to
time by our constitution; it is not for making suggestions to the
distribution.
The debian-devel mailinglist is probably more appropriate, although
filing a bug on the relevant package (not sure which one that would be,
unfortunately) would be even more so.
I've added a Cc and set mail-followup-to there to indicate that replies
should be directed there only. Please adhere to that suggestion ;-)
>I wanted to raise the issue with the default Arabic font that is used.
>I don't know if it was selected at random or if there is a reason. It's
>a weird font that's not usually used and it's not easy on the eyes (not
>as aesthetically appealing as well).
My suspicion is the former rather than the latter. I don't know if we
have a lot of Arabic-speaking contributors (possibly not), so if you
think this situation can be improved, I'm sure that will be welcomed.
-devel: where and how do we select default fonts? Personally I have no
clue :)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Bug#1082914: ITP: hexagonrpc -- userspace daemon to communicate with QDSP over FastRPC
Package: wnpp Severity: wishlist Owner: Alexandre Viard X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: hexagonrpc Version : 0.3.2 * URL : https://gitlab.com/sdm670-mainline/hexagonrpc * License : GPL-3+ Programming Lang: C Description : userspace daemon to communicate with QDSP over FastRPC This daemon is used to communicate with the Context Hub Runtime Environment, a program on the DSP that manages sensors, and to serve files to remote processor. . The daemon allow communicating with Qualcomm Digital Signal Processors with the FastRPC protocol. It provides a way to serve remote files to the DSPs and call functions to offload work to the DSPs FAQ: Q: Why is this relevant? A: hexagonrpcd is required to support sensors on phones using Qualcomm SoC. It is therefore an important ingedrient of porting Debian to many phone models. Q: Does this depend on packages not yet in Debian? A: No Q: Do you use it? A: Yes, I've started packaging it and use it everyday on my phone. Q: Are there other packages that provide similar functionality? A: No other packages brings supports for Qualcomm soc sensors Q: How are you planning to maintain the package? A: I plan to maintain it with the support of the DebianOnMobile team.
