Many thanks for clarifying the bundling of 3rd party binaries.
> On 23 Jan 2024, at 21:18, Stephen Gallagher wrote:
>
> If you are bundling any software, you need to `Provides:
> bundled(software)`. This is so we can easily locate affected packages
> when e.g. a security issue necessitates
On Tue, Jan 23, 2024 at 11:58 AM David Trudgian via epel-devel
wrote:
>
> Hi all,
>
> I currently package singularity-ce for Fedora and EPEL.
>
> Upstream, we bundle current versions of squashfuse and conmon with our source
> and own binary packages… because many distros package versions that
On Sat, Mar 21, 2015 at 1:31 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Firefox and xulrunner are bundling their own copy of jemalloc (try
strings /usr/lib64/xulrunner/xulrunner |grep jemalloc, or similarly
with /usr/lib64/firefox/firefox-bin).
Why isn't this recorded in the RPM provides
Le Mer 24 juillet 2013 16:17, Peter MacKinnon a écrit :
A generalization which I would disagree with in the Java space. I think
many projects
eventually reach steady-state where they have acquired the set of dep
bundles
they need to satisfy their runtime and test requirements. For example,
On 07/24/2013 11:03 AM, Nicolas Mailhot wrote:
Le Mer 24 juillet 2013 16:17, Peter MacKinnon a écrit :
A generalization which I would disagree with in the Java space. I think
many projects
eventually reach steady-state where they have acquired the set of dep
bundles
they need to satisfy their
Ralf Ertzinger fed...@camperquake.de writes:
Hi.
On Sun, 19 Feb 2012 22:26:20 +0100, Petr Machata wrote
Please don't do this.
The main reason being that header code from bundled boost is in
general not binary compatible with the native code from system
boost. It might maybe happen to
Thanks all for a remarkable set of advice including what not to do
(Petr M), a hint about what to do (Ralf E) and another hint how it
could be done (Aleksandra B).
I have been able to update the packaging to only bundle the boost tools
subdirectory. I presume that this should make everyone
Alec Leamas leamas.a...@gmail.com writes:
I've tried to package Adobe Source Libraries, (BZ:790628). Once again,
I'm running into bundling issues.. The situation is basically that ASL
build system expects a boost source tree to be available. This is not
just to include and link, it's for the
Hi.
On Sun, 19 Feb 2012 22:26:20 +0100, Petr Machata wrote
Please don't do this.
The main reason being that header code from bundled boost is in
general not binary compatible with the native code from system
boost. It might maybe happen to work, but is likely to fail in
obscure and hard
Hi,
I've tried to package Adobe Source Libraries, (BZ:790628). Once again,
I'm running into bundling issues.. The situation is basically that ASL
build system expects a boost source tree to be available. This is not
just to include and link, it's for the complete build process.
Not so long
On Mon, Aug 1, 2011 at 6:04 PM, Scott Baker bak...@canbytel.com wrote:
I just got back from OSCON where the virtues of perl5i were shown.
I guess schwern was giving a talk then?
Looking in yum I don't see perl5i anywhere, and I'm wondering why.
Simply because it's not a dependency of anything
Stanislav Ochotnicky wrote:
Hi everyone,
We will need to package sonatype-tycho[1] sooner or later for building
eclipse. I started looking into it a little bit and it seems things
would be much, much more simple if I was able to bundle current binary
release of tycho (or probably just some
On 02/16/2011 04:35 PM, Rex Dieter wrote:
Stanislav Ochotnicky wrote:
Hi everyone,
We will need to package sonatype-tycho[1] sooner or later for building
eclipse. I started looking into it a little bit and it seems things
would be much, much more simple if I was able to bundle current
13 matches
Mail list logo