From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: IPFire Building Packages
Date: Mon, 07 Jul 2014 11:18:23 +0200 [thread overview]
Message-ID: <1404724703.19419.14.camel@rice-oxley.tremer.info> (raw)
In-Reply-To: <53B91A6D.4060907@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]
On Sun, 2014-07-06 at 17:44 +0800, Ghislain Hachey wrote:
> On 7/6/14, 16:57, Michael Tremer wrote:
> > That's what we call bundled packages (very often libraries) and which
> > are extremely discouraged. The problem that comes with that is that when
> > a component gets updated to resolve a certain issue this problem is
> > still in the twenty other copies of the same software. Imagine that for
> > things like Heartbleed. It also consumes space, increases the build time
> > and so on.
> >
> > You should use the provided versions of those tools and libraries or
> > modify them if that is required. All other components that are missing
> > should be created as individual packages.
>
> Yeah, I understand that. My only fear is that the software in question
> is including those third party libs as deps because they are needed in a
> very particular shape (specific versions, some source changes, etc.) to
> make it all work properly as a whole. I will check with the developers
> upstream regarding this and if not I will see if I can not modify the
> build process to include those deps as individual packages in IPFire.
Bundled libs are a real worry and in the case some software requires a
certain version I would consider this software as seriously broken.
There is a reason why we have dynamic libraries and that those are
replaceable. We can easily fix bugs and security issues and those fixes
will get rolled out to the entire system. Therefore it is a must.
I wonder why I cannot find any documentation about this topic on our
wiki...
> Regarding IPFire version 3, If there are specific things I can do to
> help, sure. I'll go through information in the links to get started.
next prev parent reply other threads:[~2014-07-07 9:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-05 9:45 Ghislain Hachey
2014-07-05 14:15 ` Michael Tremer
2014-07-05 23:01 ` Ghislain Hachey
2014-07-06 8:57 ` Michael Tremer
2014-07-06 9:44 ` Ghislain Hachey
2014-07-07 9:18 ` Michael Tremer [this message]
2014-07-08 10:35 ` MySQL 5.6.19 Sascha Kilian
2014-07-08 13:10 ` Sascha Kilian
2014-07-29 8:13 ` LuaJIT Panic on IPFire Ghislain Hachey
2014-07-29 8:27 ` Arne Fitzenreiter
2014-07-07 8:49 ` IPFire Building Packages Ghislain Hachey
2014-07-07 9:22 ` Michael Tremer
2014-07-07 9:50 ` Ghislain Hachey
2014-07-07 10:35 ` Michael Tremer
2014-07-07 10:48 ` Ghislain Hachey
2014-07-11 4:18 ` Ghislain Hachey
2014-07-06 8:51 ` Ghislain Hachey
2014-07-06 9:03 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1404724703.19419.14.camel@rice-oxley.tremer.info \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox