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)

On 12 Jul 09:36, Dan Cermak wrote:

Hi İsmail,

İsmail Dönmez 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

Hi list, Dan Cermak 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 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 wrote:

Hi list,

Dan Cermak 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 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

On Tue, Jul 16, 2019 at 6:02 AM Michael Matz 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 Michael, Michael Matz 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

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