<?xml version="1.0" encoding="UTF-8"?>
<metadata xmlns="http://linux.duke.edu/metadata/common" xmlns:rpm="http://linux.duke.edu/metadata/rpm" packages="2">
<package type="rpm">
  <name>perl-Alien-Role-Dino</name>
  <arch>src</arch>
  <version epoch="0" ver="0.80.0" rel="4.14"/>
  <checksum type="sha512" pkgid="YES">4e40a11e02077dd3b911954eeb57c968175bed2fdb7f2a0d59d33146fe17767e793a692ad72f93514210b9e233391d816841e2186283efe94433446e55135276</checksum>
  <summary>Experimental support for dynamic share Alien install</summary>
  <description>Every now and then someone will ask me why thus and such Alien thing
doesn't work with a dynamic library error. My usual response is can you
make it work with static libraries? The reason for this is that *building*
dynamic libraries for an Alien *share* install introduce a number of
challenges, and honestly I don't see the point of using them, if you can
avoid it. So far I haven't actually seen a situation where it couldn't be
avoided. Just to be clear: dynamic libraries are fine for Alien, and in
fact desirable when you are using the system provided libraries. You get
the patches and security fixes supplied by your operating system.

Okay, so why not build a dynamic library for a *share* install?

For this discussion, say you have an alienized library 'Alien::libfoo' and
an XS module that uses it called 'Foo::XS' (as illustrated in the synopsis
above).

* Your Alien becomes a run-time dependency.

When you link your 'Foo::XS' module with a static library from
'Alien::libfoo' it gets added into the DLL or '.so' file that the Perl
toolchain produces. That means when you later use it, it doesn't need
anything else. When you try to do the same thing with a dynamic library,
you need that dynamic library, which is stored in a share directory of
'Alien::libfoo'.

For people who install out of CPAN this is probably not a big deal, but for
operating system vendors (the people who integrate Perl modules into their
operating system), it is a hassle because now you need this big build tool
Alien::Build and the alien 'Alien::libfoo' with extra dependencies during
runtime. Normally you wouldn't need those packages installed for end-user
use.

* Upgrades can and will break your XS module.

Again, when 'Alien::libfoo' builds a static library and it gets linked into
a DLL or '.so' for 'Foo::XS', it doesn't need the original library anymore.
If you are using a dynamic library and you do the same thing it maybe works
today, but say tomorrow you upgrade 'Alien::libfoo' and it replaces the DLL
or '.so' file with an incompatible API or ABI? Now your 'Foo::XS' module
has stopped working!

* Dynamic libraries are not portable

Dynamic libraries are widely supported on most modern operating systems,
but each system provides a different interface. For example, Linux, Windows
and OS X all have an environment variable that allows you to alter the
search path for finding dynamic libraries, but all three have different
extensions for dynamic libraries (OS X even has two!), the environment
variables are called something different, and WHEN you can change them is
different.

The Perl core has code for loading dynamic libraries as part of its XS
system on all platforms where you can build XS extensions dynamically.
Unfortunately that code isn't quite reusable for use by Alien. Alien
developers have limited time and access to many platforms, which means that
many platforms will probably never get Alien support.

Static libraries on the other hand pretty much work the same on all
platforms. Even on Windows which likes to be different, static libraries
are essentially the same as on Unix.

So all that said, why have I written this module, which provides support
for dynamic libraries? Well, maybe I am wrong, maybe it isn't that hard.
Also, maybe you don't have a choice, maybe you have found a library that
can ONLY be built using a dynamic library.

What about you? Should you use this module? It has the worked
*Experimental* in the description. The experimental aspect of this module
should not worry you, because in the situation that your Alien finds the
library from the system, nothing is different from the core Alien::Build.
The only place it is different is if you have to do a share install, and
hopefully you are only using it because you really can't build a static
library. Thus you haven't really lost anything in stability, and at worst
your Alien may work in places where it wouldn't otherwise.

So in summary, the experimental aspect shouldn't worry you, the caveats
above should!</description>
  <packager></packager>
  <url>https://metacpan.org/release/Alien-Role-Dino</url>
  <time file="1784433409" build="1784433406"/>
  <size package="397351" installed="380585" archive="381112"/>
  <location href="src/perl-Alien-Role-Dino-0.80.0-4.14.src.rpm"/>
  <format>
    <rpm:license>Artistic-1.0 OR GPL-1.0-or-later</rpm:license>
    <rpm:vendor>obs://build.opensuse.org/home:tinita</rpm:vendor>
    <rpm:group>Unspecified</rpm:group>
    <rpm:buildhost>reproducible</rpm:buildhost>
    <rpm:sourcerpm></rpm:sourcerpm>
    <rpm:header-range start="4504" end="20599"/>
    <rpm:provides>
      <rpm:entry name="perl-Alien-Role-Dino" flags="EQ" epoch="0" ver="0.80.0" rel="4.14"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="gsl-devel"/>
      <rpm:entry name="perl"/>
      <rpm:entry name="perl(Alien::Base)" flags="GE" epoch="0" ver="0.99"/>
      <rpm:entry name="perl(Alien::Build)" flags="GE" epoch="0" ver="0.99"/>
      <rpm:entry name="perl(Alien::Build::Plugin)"/>
      <rpm:entry name="perl(Class::Method::Modifiers)"/>
      <rpm:entry name="perl(FFI::CheckLib)"/>
      <rpm:entry name="perl(Path::Tiny)"/>
      <rpm:entry name="perl(Role::Tiny)" flags="GE" epoch="0" ver="1.003001"/>
      <rpm:entry name="perl(Test2::Mock)" flags="GE" epoch="0" ver="0.000121"/>
      <rpm:entry name="perl(Test2::V0)" flags="GE" epoch="0" ver="0.000121"/>
      <rpm:entry name="perl(Test::Alien)" flags="GE" epoch="0" ver="0.99"/>
      <rpm:entry name="perl(Test::Alien::Build)"/>
      <rpm:entry name="perl-macros"/>
    </rpm:requires>
  </format>
</package>
<package type="rpm">
  <name>perl-Alien-Role-Dino</name>
  <arch>x86_64</arch>
  <version epoch="0" ver="0.80.0" rel="4.14"/>
  <checksum type="sha512" pkgid="YES">7bc78ecacb607c4e1634724d201f24214530b4422b462d69c3da20d9b2d712116bea72818d14b0091cacac99036db5a9bed4c8430e6d2e604e42fb4e388382f6</checksum>
  <summary>Experimental support for dynamic share Alien install</summary>
  <description>Every now and then someone will ask me why thus and such Alien thing
doesn't work with a dynamic library error. My usual response is can you
make it work with static libraries? The reason for this is that *building*
dynamic libraries for an Alien *share* install introduce a number of
challenges, and honestly I don't see the point of using them, if you can
avoid it. So far I haven't actually seen a situation where it couldn't be
avoided. Just to be clear: dynamic libraries are fine for Alien, and in
fact desirable when you are using the system provided libraries. You get
the patches and security fixes supplied by your operating system.

Okay, so why not build a dynamic library for a *share* install?

For this discussion, say you have an alienized library 'Alien::libfoo' and
an XS module that uses it called 'Foo::XS' (as illustrated in the synopsis
above).

* Your Alien becomes a run-time dependency.

When you link your 'Foo::XS' module with a static library from
'Alien::libfoo' it gets added into the DLL or '.so' file that the Perl
toolchain produces. That means when you later use it, it doesn't need
anything else. When you try to do the same thing with a dynamic library,
you need that dynamic library, which is stored in a share directory of
'Alien::libfoo'.

For people who install out of CPAN this is probably not a big deal, but for
operating system vendors (the people who integrate Perl modules into their
operating system), it is a hassle because now you need this big build tool
Alien::Build and the alien 'Alien::libfoo' with extra dependencies during
runtime. Normally you wouldn't need those packages installed for end-user
use.

* Upgrades can and will break your XS module.

Again, when 'Alien::libfoo' builds a static library and it gets linked into
a DLL or '.so' for 'Foo::XS', it doesn't need the original library anymore.
If you are using a dynamic library and you do the same thing it maybe works
today, but say tomorrow you upgrade 'Alien::libfoo' and it replaces the DLL
or '.so' file with an incompatible API or ABI? Now your 'Foo::XS' module
has stopped working!

* Dynamic libraries are not portable

Dynamic libraries are widely supported on most modern operating systems,
but each system provides a different interface. For example, Linux, Windows
and OS X all have an environment variable that allows you to alter the
search path for finding dynamic libraries, but all three have different
extensions for dynamic libraries (OS X even has two!), the environment
variables are called something different, and WHEN you can change them is
different.

The Perl core has code for loading dynamic libraries as part of its XS
system on all platforms where you can build XS extensions dynamically.
Unfortunately that code isn't quite reusable for use by Alien. Alien
developers have limited time and access to many platforms, which means that
many platforms will probably never get Alien support.

Static libraries on the other hand pretty much work the same on all
platforms. Even on Windows which likes to be different, static libraries
are essentially the same as on Unix.

So all that said, why have I written this module, which provides support
for dynamic libraries? Well, maybe I am wrong, maybe it isn't that hard.
Also, maybe you don't have a choice, maybe you have found a library that
can ONLY be built using a dynamic library.

What about you? Should you use this module? It has the worked
*Experimental* in the description. The experimental aspect of this module
should not worry you, because in the situation that your Alien finds the
library from the system, nothing is different from the core Alien::Build.
The only place it is different is if you have to do a share install, and
hopefully you are only using it because you really can't build a static
library. Thus you haven't really lost anything in stability, and at worst
your Alien may work in places where it wouldn't otherwise.

So in summary, the experimental aspect shouldn't worry you, the caveats
above should!</description>
  <packager></packager>
  <url>https://metacpan.org/release/Alien-Role-Dino</url>
  <time file="1784433409" build="1784433406"/>
  <size package="42381" installed="57301" archive="63524"/>
  <location href="x86_64/perl-Alien-Role-Dino-0.80.0-4.14.x86_64.rpm"/>
  <format>
    <rpm:license>Artistic-1.0 OR GPL-1.0-or-later</rpm:license>
    <rpm:vendor>obs://build.opensuse.org/home:tinita</rpm:vendor>
    <rpm:group>Unspecified</rpm:group>
    <rpm:buildhost>reproducible</rpm:buildhost>
    <rpm:sourcerpm>perl-Alien-Role-Dino-0.80.0-4.14.src.rpm</rpm:sourcerpm>
    <rpm:header-range start="4504" end="16737"/>
    <rpm:provides>
      <rpm:entry name="perl(Alien::Build::Plugin::Gather::Dino)" flags="EQ" epoch="0" ver="0.80.0"/>
      <rpm:entry name="perl(Alien::Role::Dino)" flags="EQ" epoch="0" ver="0.80.0"/>
      <rpm:entry name="perl(Alien::Role::Dino::MSWin32)"/>
      <rpm:entry name="perl(Alien::Role::Dino::cygwin)"/>
      <rpm:entry name="perl(Alien::Role::Dino::darwin)"/>
      <rpm:entry name="perl(Alien::Role::Dino::freebsd)"/>
      <rpm:entry name="perl(Alien::Role::Dino::gnukfreebsd)"/>
      <rpm:entry name="perl(Alien::Role::Dino::linux)"/>
      <rpm:entry name="perl(Alien::Role::Dino::netbsd)"/>
      <rpm:entry name="perl(Alien::Role::Dino::openbsd)"/>
      <rpm:entry name="perl(Alien::Role::Dino::solaris)"/>
      <rpm:entry name="perl-Alien-Role-Dino" flags="EQ" epoch="0" ver="0.80.0" rel="4.14"/>
      <rpm:entry name="perl-Alien-Role-Dino(x86-64)" flags="EQ" epoch="0" ver="0.80.0" rel="4.14"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="perl(:MODULE_COMPAT_5.44.0)"/>
      <rpm:entry name="perl(Alien::Base)" flags="GE" epoch="0" ver="0.99"/>
      <rpm:entry name="perl(Alien::Build)" flags="GE" epoch="0" ver="0.99"/>
      <rpm:entry name="perl(Alien::Build::Plugin)"/>
      <rpm:entry name="perl(Class::Method::Modifiers)"/>
      <rpm:entry name="perl(FFI::CheckLib)"/>
      <rpm:entry name="perl(Path::Tiny)"/>
      <rpm:entry name="perl(Role::Tiny)" flags="GE" epoch="0" ver="1.003001"/>
    </rpm:requires>
  </format>
</package>
</metadata>