[opensuse-packaging] [Proposal] Stop requiring bundled static libs in foo-devel-static subpackages - use bundled() instead
Hi list, I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception). How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a: Provides: bundled(foo) = $version into the spec file? The full guidelines are here: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Librar... This has the advantage that we don't have this additional -static package, which is relatively pointless beside keeping track of bundled libraries. Querying the bundled packages can be then done as follows: rpm -qa --qf "%{name} %{providename}\n"|grep bundled or via zypper: zypper search --provides 'bundled(*)' Any opinions/thoughts? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Hi Dan, On 12 Jul 09:08, Dan Cermak wrote:
Hi list,
I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception).
How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a:
Provides: bundled(foo) = $version
into the spec file? The full guidelines are here: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Librar...
This has the advantage that we don't have this additional -static package, which is relatively pointless beside keeping track of bundled libraries. Querying the bundled packages can be then done as follows: rpm -qa --qf "%{name} %{providename}\n"|grep bundled
or via zypper: zypper search --provides 'bundled(*)'
I would say the point of the extra -devel-static packages is that, we do not want to provide static libraries unless there are exceptional circumstances (glibc-devel-static). So I'd say this extra hassle is a feature, not a bug. ismail -- Aus so krummem Holze, als woraus der Mensch gemacht ist, kann nichts ganz Gerades gezimmert werden. — Immanuel Kant SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Hi İsmail, İsmail Dönmez <idoenmez@suse.de> writes:
Hi Dan,
On 12 Jul 09:08, Dan Cermak wrote:
Hi list,
I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception).
How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a:
Provides: bundled(foo) = $version
into the spec file? The full guidelines are here: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Librar...
This has the advantage that we don't have this additional -static package, which is relatively pointless beside keeping track of bundled libraries. Querying the bundled packages can be then done as follows: rpm -qa --qf "%{name} %{providename}\n"|grep bundled
or via zypper: zypper search --provides 'bundled(*)'
I would say the point of the extra -devel-static packages is that, we do not want to provide static libraries unless there are exceptional circumstances (glibc-devel-static). So I'd say this extra hassle is a feature, not a bug.
The point of my proposal was not to make bundling static libraries (or anything else bundled) simpler. Instead I'd like to propose a way how to mark packages that bundle something without creating an additional package that is (imho) relatively pointless, beside existing as a marker (which can be also handled by a single Provides). Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
On 12 Jul 09:36, Dan Cermak wrote:
Hi İsmail,
İsmail Dönmez <idoenmez@suse.de> writes:
Hi Dan,
On 12 Jul 09:08, Dan Cermak wrote:
Hi list,
I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception).
How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a:
Provides: bundled(foo) = $version
into the spec file? The full guidelines are here: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Librar...
This has the advantage that we don't have this additional -static package, which is relatively pointless beside keeping track of bundled libraries. Querying the bundled packages can be then done as follows: rpm -qa --qf "%{name} %{providename}\n"|grep bundled
or via zypper: zypper search --provides 'bundled(*)'
I would say the point of the extra -devel-static packages is that, we do not want to provide static libraries unless there are exceptional circumstances (glibc-devel-static). So I'd say this extra hassle is a feature, not a bug.
The point of my proposal was not to make bundling static libraries (or anything else bundled) simpler. Instead I'd like to propose a way how to mark packages that bundle something without creating an additional package that is (imho) relatively pointless [...]
This is exactly what I'm saying :), it's a pointless extra process because we don't want it to be easy, basically we don't want it at all. ismail -- Aus so krummem Holze, als woraus der Mensch gemacht ist, kann nichts ganz Gerades gezimmert werden. — Immanuel Kant SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
On Fri, Jul 12, Dan Cermak wrote:
The point of my proposal was not to make bundling static libraries (or anything else bundled) simpler. Instead I'd like to propose a way how to mark packages that bundle something without creating an additional package that is (imho) relatively pointless, beside existing as a marker (which can be also handled by a single Provides).
See my other post, your idea is for several reasons no good idea. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Jul 12, İsmail Dönmez wrote:
I would say the point of the extra -devel-static packages is that, we do not want to provide static libraries unless there are exceptional circumstances (glibc-devel-static). So I'd say this extra hassle is a feature, not a bug.
There are two reasons: 1. avoid linking applications against static libraries by accident 2. easy way to find out, which applications are linked against a static library, so that if a security problem in the static library pops up, we can re-release all applications now build against the fixed static library. Security wise, static libraries are a really bad idea. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 12/07/2019 18:38, Dan Cermak wrote:
Hi list,
I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception).
How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a:
Provides: bundled(foo) = $version
into the spec file? The full guidelines are here: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Librar...
This has the advantage that we don't have this additional -static package, which is relatively pointless beside keeping track of bundled libraries. Querying the bundled packages can be then done as follows: rpm -qa --qf "%{name} %{providename}\n"|grep bundled
or via zypper: zypper search --provides 'bundled(*)'
Any opinions/thoughts?
Static libraries are only really useful for a small number of users developing very certain things in most cases. As others have been trying to reduce the amount of stuff that we have in a install this change would go against that by installing additional files that almost no one wants or needs alongside files that people do want and need. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi list, Dan Cermak <DCermak@suse.com> writes:
Hi list,
I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception).
How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a:
I have formulated this part wrongly and not as I actually intended it: the bundled static library shouldn't necessarily be put into the main package, but into the respective subpackage where it belongs (and if that means its own subpackage, then so be it). For example: a shared library bundles a static library and the static library is needed to link against the shared lib. The main package is libfoo, which ships the shared library. The foo-devel subpackage ships all the headers, the static library and Provides: bundled(evil-static-lib) Thereby only those that need the static lib actually get it, we can search for the bundled library and we have a package less. I admit that technically it *is* now a little easier to link against the static lib, but then again you should BuildRequires: bundled(evil-static-lib) which I find actually more conspicuous than a BuildRequires: libevil-static
Provides: bundled(foo) = $version
into the spec file? The full guidelines are here: https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Librar...
This has the advantage that we don't have this additional -static package, which is relatively pointless beside keeping track of bundled libraries. Querying the bundled packages can be then done as follows: rpm -qa --qf "%{name} %{providename}\n"|grep bundled
or via zypper: zypper search --provides 'bundled(*)'
Any opinions/thoughts?
Cheers,
Dan
-- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
On Mon, Jul 15, 2019 at 5:05 AM Dan Cermak <dcermak@suse.com> wrote:
Hi list,
Dan Cermak <DCermak@suse.com> writes:
Hi list,
I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception).
How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a:
I have formulated this part wrongly and not as I actually intended it: the bundled static library shouldn't necessarily be put into the main package, but into the respective subpackage where it belongs (and if that means its own subpackage, then so be it).
For example: a shared library bundles a static library and the static library is needed to link against the shared lib.
The main package is libfoo, which ships the shared library. The foo-devel subpackage ships all the headers, the static library and Provides: bundled(evil-static-lib)
Thereby only those that need the static lib actually get it, we can search for the bundled library and we have a package less.
I admit that technically it *is* now a little easier to link against the static lib, but then again you should BuildRequires: bundled(evil-static-lib) which I find actually more conspicuous than a BuildRequires: libevil-static
Fedora does require static libraries to be in their own -static subpackages, generally: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_static... The bundled() Provides is for vendored code, which is different: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2019-07-15 10:47, Dan Cermak wrote:
I would like to propose a change in our packaging guidelines, specifically the part about bundling static libraries in a *-devel-static subpackage (see: https://en.opensuse.org/openSUSE:Packaging_guidelines#Exception).
How about we follow what Fedora does and instead of putting the static lib in a subpackages, we put it in the "main" package instead and add a:
I have formulated this part wrongly and not as I actually intended it: the bundled static library shouldn't necessarily be put into the main package, but into the respective subpackage where it belongs (and if that means its own subpackage, then so be it).
For example: a shared library bundles a static library and the static library is needed to link against the shared lib.
["Dafuq?" image here] Requiring a static lib to use a shared lib? That's like... Windows import libraries. No one, absolute *no one* wants to go there. Even binutils-on-windows can do better and without the nonsense that import libs pose to modern times. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Jul 15, 2019 at 4:11 PM Kyrill Detinov <lazy.kent@opensuse.org> wrote:
On Fri, 12 Jul 2019 09:08:52 +0000 Dan Cermak wrote:
How about we follow what Fedora does
Again and again I see: "Fedora does…". Why do we need to follow Fedora every step?
We are openSUSE! We have a good practice as it is in our distribution.
Some of openSUSE's practices are good, some are bad. Same goes for Fedora. But if we aren't willing to examine and compare, how can we learn from each other? I just had a conversation on the Fedora mailing lists about adopting some of openSUSE's practices for sysuser packaging (with some tweaks and improvements to reduce scriptlets). It goes both ways, for sure. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 16/07/2019 05:41, Kyrill Detinov wrote:
On Fri, 12 Jul 2019 09:08:52 +0000 Dan Cermak wrote:
How about we follow what Fedora does
Again and again I see: "Fedora does…". Why do we need to follow Fedora every step?
We are openSUSE! We have a good practice as it is in our distribution.
We don't, but the more core stuff like packaging that we do in as close a way as possible, the less effort required for everyone involved, especially those working across both distros. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Tue, 16 Jul 2019, Simon Lees wrote:
On 16/07/2019 05:41, Kyrill Detinov wrote:
On Fri, 12 Jul 2019 09:08:52 +0000 Dan Cermak wrote:
How about we follow what Fedora does
Again and again I see: "Fedora does…". Why do we need to follow Fedora every step?
We are openSUSE! We have a good practice as it is in our distribution.
We don't, but the more core stuff like packaging that we do in as close a way as possible, the less effort required for everyone involved, especially those working across both distros.
Indeed. And in this particular case we already do mostly what Fedora (or Debian for the matter) does re static libs: namely put them into their own package or into the -devel package. (I.e. not what Dan thought Fedora does). I feel Dan wants to talks about some very specific static libs, not about all of them (for which we don't want to change anything for exactly the reasons already mentioned in this thread). Some static libs that he (and others?) call bundled. I admit I don't know what that should be, and why they would be handled different from normal static libs (i.e. be frowned upon generally). So, if anything, Dan needs to explain in more detail what he wants, for which things and for which reasons. Ciao, Michael.
On Tue, Jul 16, 2019 at 6:02 AM Michael Matz <matz@suse.de> wrote:
Hi,
On Tue, 16 Jul 2019, Simon Lees wrote:
On 16/07/2019 05:41, Kyrill Detinov wrote:
On Fri, 12 Jul 2019 09:08:52 +0000 Dan Cermak wrote:
How about we follow what Fedora does
Again and again I see: "Fedora does…". Why do we need to follow Fedora every step?
We are openSUSE! We have a good practice as it is in our distribution.
We don't, but the more core stuff like packaging that we do in as close a way as possible, the less effort required for everyone involved, especially those working across both distros.
Indeed. And in this particular case we already do mostly what Fedora (or Debian for the matter) does re static libs: namely put them into their own package or into the -devel package. (I.e. not what Dan thought Fedora does).
Actually, Debian *doesn’t* generally split them out anymore. They’re usually kept in the -dev subpackage, which is kind of annoying, because it makes it hard to force things to use shared libraries when they should (some build scripts prefer static and will use shared only when they can’t find the static ones). That’s pretty much the reason why they’re split out in Fedora and openSUSE. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Tue, 16 Jul 2019, Neal Gompa wrote:
Indeed. And in this particular case we already do mostly what Fedora (or Debian for the matter) does re static libs: namely put them into their own package or into the -devel package. (I.e. not what Dan thought Fedora does).
Actually, Debian *doesn’t* generally split them out anymore.
Meh, knowledge becomes obsolete so quickly ;-) (And, of course, meh, Debian, what are you thinking?!) Ciao, Michael.
On Tue, 16 Jul 2019 06:04:49 -0400 Neal Gompa wrote:
Actually, Debian *doesn’t* generally split them out anymore. They’re usually kept in the -dev subpackage, which is kind of annoying, because it makes it hard to force things to use shared libraries when they should (some build scripts prefer static and will use shared only when they can’t find the static ones).
That’s pretty much the reason why they’re split out in Fedora and openSUSE.
Looking at FreeBSD installation I see: % pkg which /usr/local/lib/libarchive.a /usr/local/lib/libarchive.a was installed by package libarchive-3.3.3,1 % pkg list libarchive-3.3.3,1 /usr/local/bin/bsdcat /usr/local/bin/bsdcpio /usr/local/bin/bsdtar /usr/local/include/archive.h /usr/local/include/archive_entry.h /usr/local/lib/libarchive.a /usr/local/lib/libarchive.so /usr/local/lib/libarchive.so.13 /usr/local/lib/libarchive.so.13.3.3 /usr/local/libdata/pkgconfig/libarchive.pc /usr/local/man/man1/bsdcat.1.gz /usr/local/man/man1/bsdcpio.1.gz /usr/local/man/man1/bsdtar.1.gz /usr/local/man/man3/archive_entry.3.gz /usr/local/man/man3/archive_entry_acl.3.gz /usr/local/man/man3/archive_entry_linkify.3.gz /usr/local/man/man3/archive_entry_paths.3.gz /usr/local/man/man3/archive_entry_perms.3.gz /usr/local/man/man3/archive_entry_stat.3.gz /usr/local/man/man3/archive_entry_time.3.gz /usr/local/man/man3/archive_read.3.gz /usr/local/man/man3/archive_read_add_passphrase.3.gz /usr/local/man/man3/archive_read_data.3.gz /usr/local/man/man3/archive_read_disk.3.gz /usr/local/man/man3/archive_read_extract.3.gz /usr/local/man/man3/archive_read_filter.3.gz /usr/local/man/man3/archive_read_format.3.gz /usr/local/man/man3/archive_read_free.3.gz /usr/local/man/man3/archive_read_header.3.gz /usr/local/man/man3/archive_read_new.3.gz /usr/local/man/man3/archive_read_open.3.gz /usr/local/man/man3/archive_read_set_options.3.gz /usr/local/man/man3/archive_util.3.gz /usr/local/man/man3/archive_write.3.gz /usr/local/man/man3/archive_write_blocksize.3.gz /usr/local/man/man3/archive_write_data.3.gz /usr/local/man/man3/archive_write_disk.3.gz /usr/local/man/man3/archive_write_filter.3.gz /usr/local/man/man3/archive_write_finish_entry.3.gz /usr/local/man/man3/archive_write_format.3.gz /usr/local/man/man3/archive_write_free.3.gz /usr/local/man/man3/archive_write_header.3.gz /usr/local/man/man3/archive_write_new.3.gz /usr/local/man/man3/archive_write_open.3.gz /usr/local/man/man3/archive_write_set_options.3.gz /usr/local/man/man3/archive_write_set_passphrase.3.gz /usr/local/man/man3/libarchive.3.gz /usr/local/man/man3/libarchive_changes.3.gz /usr/local/man/man3/libarchive_internals.3.gz /usr/local/man/man5/cpio.5.gz /usr/local/man/man5/libarchive-formats.5.gz /usr/local/man/man5/mtree.5.gz /usr/local/man/man5/tar.5.gz /usr/local/share/licenses/libarchive-3.3.3,1/BSD2CLAUSE /usr/local/share/licenses/libarchive-3.3.3,1/LICENSE /usr/local/share/licenses/libarchive-3.3.3,1/catalog.mk Nobody cares if it is a static or shared library somewhere. And I think: don't make it better if it works as expected in openSUSE. -- WBR Kyrill
On Tuesday 2019-07-16 18:29, Kyrill Detinov wrote:
On Tue, 16 Jul 2019 06:04:49 -0400 Neal Gompa wrote:
Actually, Debian *doesn’t* generally split them out anymore. They’re usually kept in the -dev subpackage, which is kind of annoying, because it makes it hard to force things to use shared libraries when they should (some build scripts prefer static and will use shared only when they can’t find the static ones).
That’s pretty much the reason why they’re split out in Fedora and openSUSE.
Looking at FreeBSD installation I see:
% pkg which /usr/local/lib/libarchive.a /usr/local/lib/libarchive.a was installed by package libarchive-3.3.3,1
% pkg list libarchive-3.3.3,1 /usr/local/lib/libarchive.a /usr/local/lib/libarchive.so /usr/local/lib/libarchive.so.13 /usr/local/lib/libarchive.so.13.3.3 [...]
Nobody cares if it is a static or shared library somewhere.
Pff, hobbyist projects :-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Jul 16, 2019 at 12:32 PM Kyrill Detinov <lazy.kent@opensuse.org> wrote:
On Tue, 16 Jul 2019 06:04:49 -0400 Neal Gompa wrote:
Actually, Debian *doesn’t* generally split them out anymore. They’re usually kept in the -dev subpackage, which is kind of annoying, because it makes it hard to force things to use shared libraries when they should (some build scripts prefer static and will use shared only when they can’t find the static ones).
That’s pretty much the reason why they’re split out in Fedora and openSUSE.
Looking at FreeBSD installation I see:
% pkg which /usr/local/lib/libarchive.a /usr/local/lib/libarchive.a was installed by package libarchive-3.3.3,1
Ports don't do subpackages. I'm not even sure if that's even supported in the FreeBSD pkg system. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Michael, Michael Matz <matz@suse.de> writes:
Hi,
On Tue, 16 Jul 2019, Simon Lees wrote:
On 16/07/2019 05:41, Kyrill Detinov wrote:
On Fri, 12 Jul 2019 09:08:52 +0000 Dan Cermak wrote:
How about we follow what Fedora does
Again and again I see: "Fedora does…". Why do we need to follow Fedora every step?
We are openSUSE! We have a good practice as it is in our distribution.
We don't, but the more core stuff like packaging that we do in as close a way as possible, the less effort required for everyone involved, especially those working across both distros.
Indeed. And in this particular case we already do mostly what Fedora (or Debian for the matter) does re static libs: namely put them into their own package or into the -devel package. (I.e. not what Dan thought Fedora does).
Yes, I've misunderstood the whole thing and would like to apologize for the resulting noise on this list.
I feel Dan wants to talks about some very specific static libs, not about all of them (for which we don't want to change anything for exactly the reasons already mentioned in this thread). Some static libs that he (and others?) call bundled. I admit I don't know what that should be, and why they would be handled different from normal static libs (i.e. be frowned upon generally). So, if anything, Dan needs to explain in more detail what he wants, for which things and for which reasons.
My proposal was prompted by the exiv2 package: exiv2 bundles the XMP SDK from Adobe (mostly due to historical reasons), builds a static library out of it and links against the resulting libxmp. This static library has to be shipped too, as anything linking against libexiv2 should also link against libxmp. I thought that it would be useful to put libxmp into the exiv2-devel package and add a Provides: bundled(libxmp) instead of the additional libxmp-static package. But given the reasons that were given, this hardly warrants a policy change and is also here probably not too useful. Cheers, Dan
Hi, On Tue, 16 Jul 2019, Dan Cermak wrote:
I feel Dan wants to talks about some very specific static libs, not about all of them (for which we don't want to change anything for exactly the reasons already mentioned in this thread). Some static libs that he (and others?) call bundled. I admit I don't know what that should be, and why they would be handled different from normal static libs (i.e. be frowned upon generally). So, if anything, Dan needs to explain in more detail what he wants, for which things and for which reasons.
My proposal was prompted by the exiv2 package: exiv2 bundles the XMP SDK from Adobe (mostly due to historical reasons), builds a static library out of it and links against the resulting libxmp. This static library has to be shipped too, as anything linking against libexiv2 should also link against libxmp. I thought that it would be useful to put libxmp into the exiv2-devel package and add a Provides: bundled(libxmp) instead of the additional libxmp-static package.
Ah, okay, for this case such packaging change might make sense. But it would make even more sense to just not have to deliver the static lib at all. As I understand it libeviv2 internally calls into libxmp, but the idea is not, that the whole libxmp interface is available to users as well (i.e. the user continues to only use the libexiv2 interface, which then internally might do some of its things with help of libxmp; IOW libexiv2 completely wraps/abstracts the XMP functionality). The proper fix to this is to include libxmp.a as a whole into libexiv2.so. The Real Proper Fix would be to then also hide all symbols from libxmp.a (or alternatively only export a list of wanted symbols from libexiv2.so). For that libxmp.a must be compiled with -fPIC, but it seems the XMP SDK is there in source form, so that shouldn't be a problem. By including libxmp.a (or it's constituent .o files) directly into libexiv2.so there's no need anymore to ship libxmp.a, so the whole worry collapses into happiness. For including static libs whole-sale, see the link editor flag --whole-archive. (Alternatively I wonder why it isn't enough to simply link libexiv2.so against libxmp.a (after it got built with -fPIC), which should work out-of-box if libexiv2 doesn't play games with weak symbols or dlsym on libxmp.a symbols). Ciao, Michael. PS: when I google a bit I see hints that libexiv2 actually does contain support for including libxmp whole-sale, and in addition hiding it's symbols just fine. (e.g. https://dev.exiv2.org/boards/3/topics/2137 ), so I wonder if our packaging of the static libxmp.a is not simply a past mistake which never got fixed? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (8)
-
Dan Cermak -
İsmail Dönmez -
Jan Engelhardt -
Kyrill Detinov -
Michael Matz -
Neal Gompa -
Simon Lees -
Thorsten Kukuk